DVB SimulCrypt Overview
The purpose of this document is to provide a basic understanding of DVB SimulCrypt and the building blocks necessary to implement a SimulCrypt environment. It is intended for people with some broadcast experience but not necessarily Conditional Access expertise.
DVB
DVB (Digital Video Broadcasting) is an industry-led consortium of the world’s leading digital TV and technology companies, such as manufacturers, software developers, network operators, broadcasters and regulators, committed to designing open technical standards for the delivery of digital TV and other broadcast services.
The key here is open standards, which allows compatibility across multiple vendors’ platforms in a serial fashion so long as the interfaces meet the appropriate specifications, and operational compatibility in a parallel fashion so long as the features and functions adhere to the specifications.
SimulCrypt
SimulCrypt is not a single protocol, but a specification defining the multiple protocols and algorithms, and how to apply them in protecting and monetizing content. In short, SimulCrypt allows multiple CAS vendors’ encryption systems to operate on the same Transport Stream(s). The same set of rules apply if only one CA vendor is present in the system, which allows for compatibility with any vendor’s compliant multiplexer or scrambler.
The trickiest part of getting this initially approved was that no CA vendor wanted to share their trade secrets with their competitors. So the DVB committee came up with a layered approach for a common method of scrambling, but would allow unique ways to encrypt the key used for the scrambling, and a common way of packaging and delivering the unique encryption keys to the end-user STB or IRD.
At the receiving end, the DVB specified a Common Interface (CI) between receiver appliance and Conditional Access Module (CAM), where the I/O is the same, but the internals may be unique to each CAS vendor.
The basic components required for a functional CA System include:
MUX/Scrambler (SCR), Conditional Access Control System (CACS), ECMg, EMMg, Key Generator/Encryptor, and EIS. These are functions, services, and interfaces, not necessarily separate physical devices, and as such each vendor may bundle or package them in their own unique manner.
Transport Stream
When you add CA to a DVB system, there are some specific elements that must be added to the Transport Stream(s). These must all conform to the 188-byte MPEG2 TS (13818-1) format even if they contain less than 188 bytes.
Conditional Access Table (CAT) is always on PID 0x0001. It contains the two-part SuperCasID and a pointer to the PID that carries the EMMs for that CAS system. The first part of the SuperCasID is the CA Vendor ID, as assigned by the DVB Committee. At the time of this document 162 ID ranges have been assigned. The second part is the system ID; so if a single CA vendor has multiple systems on the same network or TS they can be uniquely identified and point to unique EMM PIDs. This is especially helpful when migrating from an older system or version of smart cards to a newer one, or in cases where there might be a large number of subscribers and you want to split the control system.
When there are multiple CASs on the same network, all SuperCasIDs and EMM PIDs are listed in a single CAT.
Entitlement Management Messages (EMMs) are packetized streams that can use any valid PID, so long as it is referenced in the CAT. These are messages from the CAS vendor to the subscriber smart card, which will include entitlements, P-Keys, higher level keys, and any other data the CA vendor chooses to distribute. EMMs for all vendors are replicated across all transport streams within a network. The data rate of the EMM stream is controlled by the Mux, and the cycle period is controlled by the CAS, within the restrictions based upon the number of subscribers and type/size of EMM. This is further detailed in the EMMg section.
Entitlement Control Messages (ECMs) are added to the TS per Scrambling Control Group (SCG), per CA vendor. These provide the keys to decrypt the ControlWord (CW) to descramble the content. The same ECMs are not replicated across all transport streams, but unique to the elements on each individual TS. Each ECM will have a unique PID and contain basic information such as CA Vendor ID, CA Product(s), encrypted version of two (odd/even) ControlWords (CW), valid period, and current odd/even status.
The ECM may be tied to a unique element, an entire program, or a group of multiple programs on the same TS, at the particular level you are sharing the same CW which is associated with the SCG.
Whatever the duration of the Crypto Period (CP) as defined by the Mux, will be the refresh rate of the ECM (typically 10 to 30 seconds), while the repetition rate of that ECM is typically 300ms which is the CP boundary when the odd and even active key switches. Keys are sent out one CP in advance of when they will be utilized in a now/next fashion. This is accomplished by alternately replacing the currently inactive odd or even key.
The PMT is updated to add the ECM PID and list it as an element of the described service. The table ID does not change, but the table version number is incremented.
The SDT updates the Access Controlled and the Clear/Scrambled flags accordingly. The table ID does not change, but the table version number is incremented.
The EIT may also update Access Controlled and the Clear/Scrambled flags for a particular program or event. This is especially true for PPV events, where it also may list the CA products required.
Interfaces and Data Flow
ECMg: Entitlement Control Message Generator
The Entitlement Control Message Generator (ECMg) is also known as SimulCrypt Synchronizer (SCS) Interface. On the MUX/SCR and the CAS side, the interfaces on the devices themselves and to each other must be preconfigured. Once this is completed and correct, the Mux will initiate a connection to the CAS ECMg by sending a channel setup message, but will not initiate any sessions (open a stream) at this point in time. The channel setup message indicates the protocol version to be used and CP duration.
After determining if scrambling will be implemented at the service/program level, elementary stream level, or multiple programs with the same keys, a Scrambling Control Group (SCG) will need to be created in the scrambler at the appropriate level. The SCG will need to contain an ECM_ID (which also may need to be preconfigured), a CA Vendor ID, and Access Criteria (AC) which the CAS understands. The CA Vendor defines the format of the AC (unique to each Vendor) and the MUX specifies the values within the defined format. On the CAS side, the AC usually equates to a service, and the service relates to a product or multiple products, which relates to Boolean OR’d entitlements at the receiving end.
In addition, on the MUX/SCR side, an ECM must be preconfigured, assigned a PID, identify the CAS Vendor ID, and an ECM_ID (for SCS ver 2 and above).
Upon the request (from an EIS) to activate scrambling of the elements in an SCG, the MUX or Control system will generate a 64-bit CW (ver 1) or other fixed length CW (ver 2 and above) for the MUX to use for scrambling said elements. The elements won’t be scrambled yet, but will be in a pre-roll state equal to the length of a CP. The MUX will send a stream setup message followed by a CW_Provision message to the CAS ECMg with the AC being the common identifier between the two machines. The CW provision message is identified by the AC, and contains the first CW to be encrypted by the CA System(s), along with ECM_ID. The CAS(s) relate the AC to the product(s) and encrypt the CW accordingly. They hand the encrypted CW(s) back to the MUX in an ECM response message, identified by the AC and ECM_ID, and also containing time validity and CA product information. The mux knows by both AC and ECM_ID which ECM in the TS to embed the encrypted CW from each CAS, for each element. There can be multiple such exchanges per CP, but the CAS sends the same info back every time until the next CP. When the first CP starts, the MUX scrambles the content in the SCG using the Common Scrambling Algorithm (CSA) with the same CW that it previously sent to the CAS ECMg(s), and sends the next CW to the CAS(s) to be encrypted.
The ECM is added to the TS and referenced in the tables as spelled out above. The MUX is responsible for the ECM repetition rate.
Just as the MUX is the traffic cop for the CWs and ECM Insertion and scrambling, the CAS server is the traffic cop between the ECMg and the encryptor for interpreting the AC, encrypting the CW, adding the product’s information and handing it back to the MUX.
Once a service is being scrambled, should communications issues arise between the MUX and the CAS, the MUX will continue scrambling the content with the last known CW, basically a fixed key mode, until the communication resumes and new CWs are exchanged. This is known as a “hung CP”. This is also the case if the CAS goes off-line or is rebooted. However, if during this hung CP, either the mux is re-set or it is told to stop scrambling, the content will be forced in the clear and unable to be scrambled, until SCS communication is resumed.
EIS: Event Information Server
All of the above just creates the interfaces and sets the rules for when an element is to be scrambled, but it doesn’t actually start scrambling until it is told to scramble, what to scramble, and when.
That’s where EIS comes in. EIS may or may not actually be a server, but a function that is typically hosted on a server that performs other functions. The EIS function can be generated from the MUX, the encoder management system, the CACS, or even a VOD or middleware server. No matter what device is hosting the EIS service, it must be on the CAS LAN, and must be configured to tell the MUX what to scramble and when.
EMMg: Entitlement Management Message Generator
The CAS(s) EMMg(s) connect to the MUX(s) using Private Data Generator (PDG) protocol, however, on the MUX side this is usually configured on the same physical port and IP address as the SCS and reserved for EMMs, so that it is isolated from any other PDG interfaces. This allows the MUX to be configured to process the incoming data specifically as EMMs, and not treated like any other external data.
The EMM Data can be transmitted as TCP or UDP, or UDP data with TCP control.
On the MUX side, the EMM PID must be preconfigured in the outbound TS, EMM_ID and Data_ID defined, and bandwidth allocated. At this time, the SuperCas_ID and the TCP port (socket) are defined, which allows the MUX to generate the CAT, and embed the incoming data from a specific TCP socket into the appropriate TS EMM.
The EMMg initiates the connection to the MUX/PDG with a channel setup message. Once the V1/V2 channel is negotiated and established, the EMMg sends a stream setup message. Then the data provision message dictates TCP or UDP data, followed by a BW allocation message and response.
Finally, EMMs can be sent from the CAS to the MUX. These can be either in packets (13818-1) or sections, which is also pre-configured at the CAS and MUX. If they are sent as sections, then it is the mux’s job to do the packetization, with less than 250ms delay between reception and TS output.
The contents of an EMM are uniquely defined by each CA vendor, and most CA vendors have many different types of EMMs. Some commonalities include smart card entitlement messages and P-Keys.
Smart card entitlement messages are pretty much what they sound like; a message to the smart card, by SN or unique key, listing the products that it is entitled to decrypt, the duration of that entitlement if not refreshed, and other similar messages. The time it takes for a CAS system to perform an entire smart card refresh cycle is determined by three things: the length of the entitlement messages, the bandwidth available in the TS, and the number of smart cards in the database. These smart card refresh cycles are typically performed as a background task, at regular intervals, with “Express EMMs” being able to interrupt the cycle at the next available interval. Some CAS vendors also send out “Positive de– entitlement” EMMs for de-activated smart cards or when a subscriber opts for a lower tier of programming.
P-Keys are the keys sent to the smart cards by a CAS that enables them to decrypt the encrypted CW in the ECM, and then use the decrypted CW to descramble the scrambled elements of the program as defined by the SCG. As you may have guessed, the P-Key is usually encrypted by a higher–level key and a stronger algorithm with a longer cipher length than the CW itself. The duration of the P-Key and the refresh and repetition rate thereof is also defined by the CAS vendor, as is the number of more secure layers above the P-Key itself.
In addition, other EMMs might contain things like mail or text messages to the STB for On Screen Display, or other command messages through the CAS interface to the STB HW such as “Force Tune, or “Upgrade SW”.
(P)SIG: PSI or SI Generator
Another element that is commonly provided with a CAS system is a PSI or SI generator, or a combination of both. In most compression systems the PSI is generated in the encoders and the SI is generated in the multiplexer, which also typically performs the function of aggregating the PSI from the encoders and combining and updating the tables. This is, however, not always done in the mux, or all functions or tables might not be provided. By augmenting it with a CAS provided PSIG, you can fill the gaps where the mux leaves off, or pick and choose which device you want to use for each table. In addition, you can have the mux generate the specific table, with additional data to be provided from the PSIG and inserted into the mux-generated table. One common instance might be the EIT, where the regularly scheduled content/channel guide is generated by the mux, but specific event data is inserted by the CAS and merged in the mux.
The connection and communication model is pretty much the same as the PDG above. Because either the MUX or the PDG can act as the carousel agent, however, there are a few extra parameters and hand-shaking steps required for determining the roles.
Receivers
Any previous mentions of smart card should be interpreted as “Receiver CA Function”. This is because the DVB committee originally specified the receiver as having a CI-CAM slot that is compatible with all CA vendors’ CAMs, a vendor-specific CI-CAM, and a corresponding smart card. Through the evolution of STB design, many STB vendors have dropped the CI-CAM slot and CAM in favor of embedding the core CAM components on the main board or a daughter board within the STB. This alone cuts the cost of the STB in half, but it is no longer flexible to work with any CA system, it will only work with the CA vendor who provided the CAM components.
For every CA vendor, even though the CAM to STB interface is common and standard, the Internal CAM to smart card interface is unique. This also applies to STBs with embedded “CAM” and smart card interfaces. The contacts on the smart card, chips used, method of communications, security elements, algorithms, and even the formatting of the storage are unique to each CA vendor.
Although the implementation is unique, some of the commonalities include the ability to store a list of CA products (entitlements), typically with validity periods and countdown capability, a hierarchy of keys, and the ability to use a P-Key to decrypt a CW, and use the clear CW to descramble the content and send it back to the decode function within the STB. This is also the same for the next generation of STBs which not only include embedded CAM functionality, but also include an embedded smart card, or secure client.
As soon as a receiver locks onto the RF carrier, it looks at the NIT for the additional carrier’s tuning parameters. Once that step is complete, the receiver reads and parses the PAT (PID 0x0000) and CAT (PID 0x0001). Contained within the CAT is each SuperCas_ID with a reference to the CAS vendor’s EMM(s). If the receiver has a smart card with a specific CA vendor ID that is also contained in the CAT, it will stay permanently tuned to the referenced EMM PID to listen for entitlement message, keys and other CA vendor specific messages, and route that data to the CA function in the STB.
When the receiver tunes to a channel that is running in the clear, assuming that the SI and PSI tables are also correct, the demux chip sends the appropriate elementary streams to the appropriate decode functions, bypassing the CA function. If the Access Controlled and CLR/SCR flags are set to “1”, the scrambled content is automatically sent to the internal CA function, whether the content is actually scrambled or not. If the content is not scrambled, the CA function does nothing and returns the clear streams back to the decode function, just as if it had descrambled them.
The CA function will read the appropriate ECM to see what product the CW is scrambled with If the flags are properly set and the content is scrambled. Then it checks the entitlements in memory that came from EMMs to see if it is entitled for that product. If it is, it decrypts the CW and descrambles the content. In reality, if it is entitled, it has already decrypted the CW in advance because of the present/following nature, so that it will be able to descramble the content with minimal delay and no hiccups between CWs.
Barely worth mentioning are CI-plus-CAMS. These have the same CI-CAM physical interface, but a different electrical interface, which allows them to operate at higher speeds, providing the ability to pass high-speed TSs as typically found on DVB-S2 or 256-QAM carriers. New handshaking has been implemented on both sides of the CI to negotiate speed, or fallback to non-CI-plus if either side is not CI- plus compatible.
Subscriber Management System (SMS)
One item that is not covered by any DVB or SimulCrypt specifications, but a necessary evil in most CAS environments, is a Subscriber Management System (SMS). The CA system itself only has knowledge of smart card IDs and CA products, as in “smart card ID 123456789 is entitled for Products 1, 3, 5, 7, 9 and 11”. And a product can be a single element, program, or group/tier or bundle of programs, depending on how your SCGs are configured on the MUX side, and your AC-to-product relationship on the CAS side. Unless you like juggling multiple spreadsheets to entitle a specific user for specific content, an SMS is the way to go.
The SMS contains a database of smart cards and products as well as provides the GUI and human-usable definitions of the same data. It allows you to enter and maintain full subscriber address and contact info, and converts CA product definitions into programs/tiers/bundles/packages, so that you can say “John Smith is entitled for the Basic Package plus the Movie Package, and not the Sports Package”, as opposed to the method in the previous paragraph.
Not only does the SMS allow you to do a look-up and view present status, it also provides a historical audit trail and generates common or custom reports. This is also the interface to internal or external billing systems, credit card clearing houses and banking systems.
Because the SMS Interface (SMSi) is not defined in any spec, each CA vendor has their own unique SMSi, which includes the communications protocols, methods, messages, and data contained within the messages. Therefore, there is no one individual SMS system that can interface with multiple CAS vendors off-the-shelf.
Summary
When the DVB committee sets out to create a spec, many ideas and concepts are reviewed and even the wildest application scenarios are considered. The group does a good job of providing a fair and balanced playing field for all vendors, for the benefit of all operators. By the time a spec is published, it has been well thought out and undergone many reviews. The result is a well-defined framework that can support a flexible environment that any compatible vendor can interface into.
When it comes to SimulCrypt, this is extremely important to have a common set of rules and interface specs, so that a single operator can select any mux vendor and provide simultaneous encryption of the same content by multiple CAS vendors.
For more technical information, start with ETSI TS 103 197.