On the security of broadcast flag-type systems

| Comments (3) | TrackBacks (1) |
EFF reports more action on the Broadcast Flag front. The broadcast flag, if you don't know, is control information attached to audio or video that tells compliant devices whether it can save, copy, etc. Such devices will of course be forbidden from exporting protected content in non-protected form or sending it to non-compliant devices. So, for instance, your HDTV tuner wouldn't be able to send decoded copies of broadcast-flagged data to a general purpose computer for processing. Think of it as a roach motel for data.

It's obvious why the broadcasters want this: they want to extract monopoly rents by selling off each individual use of their content rather than giving people the kind of blanket capability that they have now. Consider a TV show that you've taped off the air: you can make as many copies as you want, send them to your friend, whatever. The networks would clearly prefer to charge you for each viewing and definitely don't want you making long-term copies and giving them to friends. Ignore for the moment the question of whether this sort of price discrimination is a valuable thing. Ask instead why this means you need the broadcast flag.

There are two big problems with the broadcast flag as specified: First, it's not very secure. Consider the security properties of the broadcast flag system. It creates a closed environment of machines all of which supposedly enforce correct security policies. As long as none of the machines are compromised, then this all works fine. But consider what happens if a single machine--or more likely class of machines--is compromised. Anyone who owns one of those machines can export any content he receives in plaintext form. Allan Schiffman used to call this type of system a "distributed single point of failure" (he was talking about thinnet).

Of course, you don't need to have a compromised device in order to bring about this scenario: it's fairly easy to build an HDTV-capable device that doesn't respect the broadcast flag. Indeed, that's the situation with the HDTV-tuners you buy today. So, if pirates (for instance) want to record HDTV signals off the airwaves and then burn them to DVD, they won't have any problem doing it. The only people who are going to be seriously inconvenienced here are consumers.

This brings us to the second big problem: the broadcast flag is horribly inconvenient for consumers. This inconvenience comes in three flavors. The first is intentional: all sorts of things you'd want to do with the content--and that you can currently do--such as time-shifting, space-shifting, etc. will be prohibited by the broadcast flag. That's the point, after all. The second two inconveniences are collateral damage. It gets much harder to write generic content (image/audio/video) processing applications because they need to keep the content from being exported. This brings us into the whole Trusted Computing mess.

Finally, because the content is actually being transmitted in the clear, in order for the system to work it needs to be illegal to make non-broadcast-flag decoders. This is essentially fatal to software-defined radio type systems unless they themselves run on trusted computers, which means that you won't be able to make SDRs that run on Open Source operating systems. This doesn't sound like a big deal right not, but it precludes a lot of really cool applications of SDR that are likely to be around the corner as processors get faster.

Consider the following alternative design:

  1. The networks broadcast their traffic in encrypted form along with signed access control restrictions.
  2. The encryption keys are restricted to devices which obey the access control restrictions on content.
  3. Compliant devices never export plaintext but rather re- export ciphertext to any device. They can also re-encrypt to other compliant devices, for instance if they transform the data before export.

From the perspective of both security and convenience, this design dominates the broadcast flag. It's more secure because a generic RF-receiver can't receive the content. You actually need the keying material. This means you need to compromise a legitimate unit, which puts at least a modest barrier in the way of piracy. I don't want to overstate the case here: this kind of technology is used for pay satellite television and it gets broken pretty regularly, but the networks have managed to impose pretty substantial costs on the pirates and do a pretty good job of protecting their revenue stream.

A cryptography-based design is superior from a convenience perspective as well, since it means that there's no need to impose legal restrictions on receiving technology. The networks can simply impose restrictions on receivers that can decode their signals--just like the situation with DVDs. Now, it's certainly true that this may end up with everyone having a "secure content"-enabled unit, but maybe not. And in any case it wouldn't get in the way of people developing new, cool applications on spectrum not dominated by the radio and TV networks. And of course it's possible--though not guaranteed--that there would be enough content broadcast without restrictions that you could make a good business selling products that just didn't play secure content.

It's obvious why the networks don't want to go this route, of course. It's a pain in the ass to manage this kind of cryptographic infrastructure and it's certainly much easier to just have the FCC impose the costs on consumers. However, seeing as the entire purpose of this scheme is increased revenue extraction, it's hard to see why consumers should be legally required to bear the costs when a workable alternative exists.

1 TrackBacks

Listed below are links to blogs that reference this entry: On the security of broadcast flag-type systems.

TrackBack URL for this entry: http://www.educatedguesswork.org/cgi-bin/mt/mt-tb.cgi/548


There was a good analysis from CDT a few years back about the broadcast flag:


They write, regarding broadcast encryption:

'Several of the flag scheme’s critics have suggested “encryption at the source” as an alternative to the broadcast flag. Under such a solution, broadcasters would encrypt their broadcasts rather than broadcasting “in the clear” and having encryption take place at the receiver level. This is the content protection approach employed in cable and satellite television systems.

'Although this solution may be more technically elegant, and provide better protection to content, many view it as politically infeasible because of the US tradition of free over the air broadcast. Additionally, encryption would leave those television receivers in consumer hands today unable to receive DTV broadcast content, and consumers would have to buy converters[37]. Estimates for the cost of these converters range widely, but they would probably cost on the order of $100 each for several hundred thousand users. In its ruling, the FCC cited concerns over “the implementation costs and delays” associated with a solution based on encryption at the source as its reason for preferring the flag approach.38

'[37] We also heard that since high definition digital television (HDTV) is being transmitted in compressed form, it requires converters and decoders in order to be viewed on standard digital televisions anyway.'

Point taken, but the broadcast flag shifts imposes substantial costs on *new* HDTV users, who will presumably vastly exceed the number of current HDTV users.

Re: HDTV needs converters and decoders anyway

I think the cost of mpeg decoders and streaming encryption & decryption chips are at least a factor of ten apart. Probably more. Mpeg chips are being turned out by the metric ton to go into dvd players and soon all sorts of consumer video devices. Each cipher chip has to be custom designed for the type of encryption scheme you use.

Leave a comment