"Perry E. Metzger" <perry@piermont.com> writes:
Not true at all, Mike. Consider the threat model.
You have a single satelite sending out a single encrypted stream to millions of people.
That is correct.
Your goal is to let some people view the signal and others not view the signal...
That is also correct.
...in spite of the fact that some of the people viewing the signal might be willing to leak information (such as the keys!) to the people who aren't supposed to view it.
Certainly anyone authorized to view the program can "leak" that program to other users. Indeed, with the European system, people have set up transmitters which simply run off a decoder that subscribes to every program. Not exactly subtle, but in jurisdictions where such activity carries no significant legal sanctions, an efficient approach to the problem. Much like the case of sending an encrypted PGP message to multiple recipients. One or more of the legitimate recipients can tell others what the message says. Not a negative reflection on the strength of PGP, and certainly not something I spend a lot of time worrying about. In the system I described, a person might make a lower bandwidth attempt to defeat the system by leaking either the periodically changing random session key used to encrypt the video stream, or the unique cryptographic key belonging to a particular smart card authorized to view the program. We have postulated that the latter is not recoverable even by destructive reverse engineering of a specific card, and were such information to be compromised upstream where the programming originates, it would only be necessary to reissue new cards to the affected subscribers and cancel the old ones. Leakage of the periodically changing random session key directly would require significant surgery to a working smart card, although it might be recovered by tapping appropriate points in the circuitry. However, anyone using such information for unauthorized reception would require a constant connection to a provider to continually update the key, which would be awkward, and not likely to be done by a large population of people in a way which was inconspicuous to LEAs. I can't imagine that a significant market for pirate equipment could be built around any of the attacks described above. Indeed, a significant market exists only for ersatz smartcards which a person can purchase for a fixed price, stick in their decoder, and then forget about. The system I described would certainly preclude such a device from being built. I spent a bit of time on the Web last night reading up on the various attacks which were mounted against DSS and the earlier European VideoCrypt system. The implementors put what they though were a lot of cute features into the cards, including the ability to reprogram them from upstream when software updates were needed. Unfortunately, rather than relying totally upon strong cryptography within a tamperproof module, they also employed easily forged checksums to validate commands sent to the cards, and "security through obscurity" as to what those commands were. The ultimate result was that the cards were being updated with new software almost constantly, and the hackers were issuing updates to the pirate versions within hours each time this was done. Given the way the system had been implemented, there was really no way prevent this from happening.
In other words, you are trying to do something that no amount of technology can really do. At best, by using enough tamperproof equipment you can stave off the inevitable for a while.
If what you are trying to do is make sure no subscriber will ever disclose, by any means, the contents of a program to a non-subscriber, then of course you are right. There is no technology which can prevent this. If, on the other hand, you wish to prevent clever engineers from looking at the system with instrumentation, and then trotting off and stamping out millions of their own smart cards, which interoperate with the legitimate ones and decode all programming transmitted, this is something that can certainly be done by using strong cryptography correctly. It is this latter goal which the VideoCrypt system, and now apparently the DSS one as well, failed to accomplish. -- Mike Duvos $ PGP 2.6 Public Key available $ mpd@netcom.com $ via Finger. $