On Thu, 3 Mar 2005 21:23:35 -0800, Brad Templeton <[EMAIL PROTECTED]> wrote: > On Thu, Mar 03, 2005 at 09:21:05PM -0500, Joseph A. Caputo wrote: > > Brad Templeton wrote: > > If I were trying to make it really secure, I see a few things I could > do. It's limiting, but you could put all video-needing operations > right into the decoder card. For example, rewind/ff/seek would be > done via the card. OSD would also be done that way, though frankly > you want to do that in the card anyway. The card could give > unencrypted access to all the metadata streams if they are not > unencrypted already, and to the index to allow the controlling software > to know how to seek. The card could allow access to a scaled down > version of the stream which would allow things like preview window, > program guide display, picture in picture, and yes, even commercial > elimination. > > All the features we've thought of so far, but none or few of the ones > we will think of in the future. >
ILast year I sat down and read the Cable Card specs and security extensions. I haven't done any bare metal discovery for a while, but the security extension is pretty tricky. The cable card and the slot on the other side have an exchange protocol which relies on two sets of keys (one is a static exchange the other is dynamic) and the process has a licensing Board/Consortium who won't license the device until you abide by their rules. (seemed they might have a patent or two). Their rules say the stream will be protected if the protection bit is on coming off the cablecard. So like Brad said, I seem to remember a disable feature so they may be able to detect a type of workaround and deny it through the cablecard. It's been a year since I read the spec, so I'm a little hazy on it. Alan
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
