CableCard™ has some primary security components that establish trust between interfaces and decrypt and encrypt content. That makes it interesting to me.

In this article I plan to highlight the noteworthy areas in the freely available/public CableLabs documentation. Let’s discussion the primary security mechanisms implemented in the CableCard specification. Let’s get get some terminology down.

Caveat: While I’ve worked on a number of Commercial CableCard projects, I won’t be discussing those and I won’t be giving away any secrets. Everything you read in this article is based on details from publicly available documentation.

OpenCableTM Specifications:

• OC-SP-CCCP2.0-I12-120531 - CCCP - CableCARD™ Copy Protection 2.0 Specification

Brief Overview:

CableCard devices abstract the different proprietary US Cable TV systems into a single common access mechanism that allows third parties to build set-top-boxes or other TV reception devices. With a single standard interface into a CableTV system, and a set of protocol specifications, devices can tune television, and where permitted, receive high-value commercial TV content in an agreeable encrypted format.

In order to maintain high levels of security, third party device manufacturers are required to have their products certified by CableLabs (A central body funded by the US Cable TV operators). These certification tests validate end-to-end trust and security between products, device stability, safety and other things.

I’m interesting in discussing the trust relationship between a third-party device, such as a Tivo, and a CableCard.

How do they trust each other, how is content transmitted securely? What can we learn by examining the public specifications and freely available reference materials?

Card and Host Mutual Authentication

CCCP Section 4.1 outlines the process.

The Card and Host authenticate each other by a process of exchanged messages, calculations using stored secrets, and confirmations that the results meet specific criteria.

Secrets

Based on a quite read of the CCCP, I’ve made a list of the important secrets and certs.

For CableCard:

• c0. Section 5.1.3- Diffie-Hellman shared secret (DHKey) 1024 bits
• c1. Section 4.1a - Diffie-Hellman (DH_pubKeyc) public key from c0. - Section 5.1.2/3, DH prime (DH-n) is 1024 bits - Section 5.1.2, DH base (DH-g) is 1024 bits
• c2. Section 4.1a - Diffie-Hellman (DH) generated random integer.
• c3. Section 4.1b - X509 Device Certificate (public key and private) - No mention of passing the public key to the Host - In section 5.1.1
• c4. Section 4.1c - Root Certificate, used to sign all h5 and c5
• c5. Section 4.1c - Manufacturer Certificate - Used to sign c3
• c6. Section 4.1c - Signature of c1
• c7. Section 4.1e - DHKey - a shared secret between CableCard and Host - Section 5.3.4 - Stored in non-volatile memory
• c8. Section 4.1f - AuthKeyC - Card to Host shared auth key. 160 bits - Section 5.4 - Stored in non-volatile memory
• c9. Section 4.3 - Random integer ‘x’ used for DH. - Section 5.1.3 DH Private Exponents x,y 160 bits - Generated for each different binding
• c10. Section 4.3 - CPKey - Copy Protection Key calculated from c9 - Using SHA-1 and DFAST [1], [2], [3]. - M-card multi-stream, each stream has its own CPKey/DESKey. - Table 8.2.1 - M-mode uses two 56-bit values

For the Host (Tivo, TV, set-top-box):

• h0. Section 5.1.3- Diffie-Hellman shared secret (DHKey) 1024bits
• h1. Section 4.1a - Diffie-Hellman (DH_pubKeyH) key derived from h0.
• h2. Section 4.1a - Diffie-Hellman (DH) generated random integer.
• h3. Section 4.1b - X509 Device Certificate (public key and private) - Device public key is shared with the CableCard.
• h4. Section 4.1c - Root Certificate, used to sign all h5 and c5
• h5. Section 4.1c - Manufacturer Certificate, used to sign h3/c3
• h6. Section 4.1c - Signature of h1
• h7. Section 4.1e - DHKey - a shared secret between CableCard and Host - Section 5.3.4 - Stored in non-volatile memory
• h8. Section 4.1f - AuthKeyH - Card to Host shared auth key. 160bits - Key is set to Card during Copy Protection Init Sec 5.2 - Section 5.4 - Stored in non-volatile memory
• h9. Section 4.3 - Random integer ‘y’ used for DH. - Section 5.1.3 DH Private Exponents x,y 160 bits - Generated for each different binding
• h10. Section 4.3 - CPKey - Copy Protection Key calculated from c9 - table 8.2.1 - M-mode uses two 56-bit values
• h11. Table 8.2.1 - KsA/B (DFAST Seeds) two of them, 128 bits each

Section 4.3, triple-DES is used to protect content from the CableCard to the Host, using c10 for encrypt and h10 for decrypt (symmetrical scheme, so they’ve compute the same secret key).

Section 4.5, M-Card mode uses triple-DES (ABA) in ECB mode. So any encrypted data being transmitted from the CableCard to the Host using a standard symmetrical encryption scheme. No all content is necessarily transmitted in an encrypted for, the CableCard firmware decides this based on CCI flags specified by the CableTV Operator itself (traditionally negotiated via legal contracts with the content providers, FOX, HBO, AMC etc).

Evaluation certs are available:

Sample evaluation certificates for c3, 4, 5 and H3, 4 5 are available for download from the CableLabs website here [4].

Authentication Parameters

Section 5.1:

The Card SHALL contain a CHICA-authorized X.509 version 3 Device Certificate [X.509] and matching private key used for creating digital signatures. This certificate includes a unique ID and the public key provided to other devices to validate the digital signatures.

Item h3 and possibly c3 (optional).

Section 5.1.1

The Device certificates h3 are validated by the manufacturer certificate h5 which in turn is validated by the root certificate h4. All the certs are chained and validated as signed by the CableLabs signing authority.

Its typical for the CableLabs root (c3/4/5) certs also to be present in the CableCard, so aid with the verification of the cert validation chain.

Diffie-Hellman Public Key Calculation

An evaluation implementation of DFAST has been made available by CableLabs [1][2][3].

A cursory glance at the eval code suggests that CableCard and Host implementations of the Production (secret) version of this software probably has a 256 * int sized pair of byte substitution tables, tables of numbers that never contain the same value twice. This should be easy to find if you had access to non-encrypted firmware for either a CableCard or Host device. Have you checked the Service Channels of your cable plant recently?

I’d also hazard a guess, looking at the eval code, that the coefficients that are in static arrays before the two translation tables are also placed close to or near the translation tables in any production firmware. This is also interesting.

Result is this DFAST computation is DKHey.

The Card SHALL derive a Diffie-Hellman (DH) public key and its signature as follows: generate a random private exponent, x, where 1 ≤ x ≤ n –2; compute its DH public key as DH_pubKeyC = gx mod n; compute SIGNC by signing DH_pubKeyC with its X.509 private key.

This comment is interesting. A publicly visible item of data, calculated at card bind time (when the card is paired) is likely stored in non-volatile memory, perhaps a secure key store or a simple flash device with minimal protection. This data item may be stored near or in the same place as all the other secrets. This is useful to know.

A logic analyzer on the control bus could visually inspect the contents of AuthKey and later analysis of a device (or memory image) of a device, may yield interesting near-by neighbor data items.

After calculation of AuthKeyC, the Card SHALL request AuthKeyH from the Host using the CP_data_req() APDU with Datatype_id = 22.

DFAST is also used to calculate the h10/c10 copy protection key, hmm.

End.