Mail Delivers Insight on Downloadable Security


The tricky part in translating the developing work that is “downloadable security” is the very fact that it is developing work, or clumps of ideas huddled deep within the cone of silence.

Plenty of public information exists about why it’s needed, and when — witness the multiple mentions within the Federal Communications Commission’s recent ruling, released on St. Patrick’s Day.

But gathering the particulars of how downloadable security works, or will work, remains fairly shrouded. Or at least it was until this year’s NCTA Technical Papers landed in the mail stack.


Each year, the National Cable & Telecommunications Association compiles the technical papers delivered at its National Show. My copy showed up last week. I prowled through it with fiendishly nerdy interest, as I do every year.

And there it was: A paper, simply titled “Downloadable Security,” and written by one of the chief architects of the industry’s plan: Jim Fahrny, a Comcast Corp. “fellow” engineer.

Big software projects tend to begin with architectural work. Downloadable security is no exception. Fahrny’s paper details the architecture needed to perform media protection without a CableCARD or a proprietary chip. This week’s translation aims to highlight Fahrny’s work on the technical beginnings of “downloadable security.”

First, three quick lingo translations. There’s “embedded” security, also known as “integrated” security, which is what’s used now in digital cable set-tops. What’s embedded is a secure-but-proprietary microprocessor. The secure chip contains the secrets needed to authenticate a new box when it enters the scene.

Then there’s “separable” security, such as CableCARDs, in which all the secret stuff is packaged onto a card that can be removed and replaced, if compromised.

“Downloadable security” is envisioned as a nonproprietary way of securing digital content. Secret stuff needed to protect channels is electronically sent to receiving devices, in a manner that’s renewable if compromised.

The secrets themselves can be proprietary, but the chip that handles them isn’t. That way, consumer-electronics companies can build gear that works on any cable system in the country, regardless of how the security secrets are generated.


How is it that “downloadable” security slips through the Federal Communications Commission’s ban on embedded security, if it sits on a chip that’s embedded in a set-top or TV? The answer appears in Paragraph 35 of the FCC’s rules:

“Downloadable security comports with the rule’s ban on the inclusion of conditional access and other functions in a 'single integrated device’ because, by definition, the conditional-access functionality of a device with downloadable security is not activated until it is downloaded to the box by the cable operator. Thus, at the time the consumer purchases the device, the conditional access and other functions are not 'integrated.’ ”

Operators have until next July to outfit all going-forward digital boxes with separable security. But the FCC and the MSO community are keenly interested in perhaps skipping the separable part and going straight to downloadable.

A Dec. 1 deadline exists to outline the downloadable plan to the commission. Regular progress reports, both from cable and the consumer-electronics community, will punctuate the time until December.

On a business level, the move to downloadable security is anticipated to cover not just broadcast digital video, but also video on demand, interactive games and “portable” video. That’s where individual shows can be shifted onto a player in a way that keeps copyright owners happy. (Technologists sometimes call this the “trusted domain,” or the “assured-service domain.”)


One of the big ideas in downloadable security is the notion of the blank chip. It gets built into digital cable-ready devices and set-tops, and receives its security “personality” at the time the device is attached to the plant.

After the box and the headend have assured each other that they’re not imposters (see the April 11 translation), the blank chip — known industrially as a “Secure System On a Chip,” or “SSOC” — goes about getting its security traits. Key exchanges happen; digital signatures are included to protect the security image from being modified along the way. All exchanges are encrypted to assure they can’t be seen by interlopers.

Here’s how it looks from another, more tangible angle: Consumer Bob goes shopping for an HDTV set. Let’s say that set already has a blank security chip inside. He takes it home and connects it to cable.

In the background, the cable plant gets busy discovering Bob’s TV. After the headend and Bob’s TV establish each other’s trustworthiness, Bob’s TV receives a secret key.

The key is to unlock a downloaded security package, which contains a Bob-specific conditional-access client, keys and initial entitlements. In a nutshell, it learns which services Bob is authorized to get based on what he ordered.

And because the new, downloadable security method must achieve the same business goals as the CableCARD — to make cable-ready hardware geographically portable — let’s say Bob moves. In his new place, he plugs his HDTV into the cable outlet.

When the headend controller of Bob’s new cable provider discovers Bob’s TV, it sees an unfamiliar security package. It tells the TV to delete it and replace it with a new software image.

That’s an overview of the early, architectural work that is downloadable security — and the end of this unintended miniseries on conditional access and encryption. As the momentum builds, translations will follow. For now, it’s probably time to let the ingredients cook.