BBC's Plan To Kick Open Source Out of UK TV 302
bluec writes "Generally speaking, the BBC isn't allowed to encrypt or restrict its broadcasts: the license fee payer pays for these broadcasts. But the BBC has tried to get around this, asking Ofcom for permission to encrypt the 'metadata' on its broadcasts – including the assistive information used by deaf and blind people and the 'tables' used by receivers to play back the video. As Ofcom gears up to a second consultation on the issue, there's one important question that the BBC must answer if the implications of this move are to be fully explored, namely: How can free/open source software co-exist with a plan to put DRM on broadcasts?"
Re:Strange question (Score:5, Informative)
In an open-source solution you can download the source and a debugger and see exactly which bytes you need to patch to break the DRM.. Finding 09 F9 was hard when hackers had a 15MB memory dump to scour, but it wouldn't be hard at all with the full source code. You don't seem to realize that an "encryption system" needs to store its key (or a method of obtaining the key) in the source or else the client can't view the content at all.
You can do some Bad Things like using a weird memory manager that puts instructions in unpredictable places but that only increases headaches all around and is still breakable.
Re:Strange question (Score:3, Informative)
If you can read the source code of a program, the function can be modified and thus a hypothetical open source DRM program could be engineered to decode the media wtihout implementing DRM's limitations. Which is much of why DRM is so disgusting. Not only does it severely limit what someone can do with their legally bought media, it also must be proprietary in order to hide the key from the user themselves.
Re:Why does DRM exclude open source? (Score:5, Informative)
Real cryptographers don't try to keep the intended recipient of the message from being able to access the encryption key either. The problem is that DRM is a flawed system, you can't stop the intended recipient of a message from doing what they like with your message after they receive it... in the end they will find a way to break your system, and the fact that you had to make it possible for them to decrypt it means that you can't rely on them not being able to decrypt it.
Re:Strange question (Score:5, Informative)
> an "encryption system" needs to store its key (or a method of obtaining the key) in the source or else the client can't view the content at all.
This is untrue for an "encryption system". It is generally true for a DRM system.
GPG, PGP, many open source projects implementing encryption systems such as AES, DES, etc... have no qualms about their source being public. Because the keys do NOT need to be included in the source.
DRM system such as DVD encryption however requires the player to be able to decode the disc for playback, but they don't want the user to be able to playback on non-certified devices. This means the player has to have a key to decode the files. Keys don't need to be stored in the source, but the source would reveal how the key was used. It would reveal implementation problems that could make breaking the DRM easier.
Re:BBC (Score:4, Informative)
Re:Strange question (Score:3, Informative)
Encryption strength depends on the key, not the algorithm.
Actually they're both important. For example, XOR encryption is remarkably weak in most cases. Especially based on your further comments, I think what you really meant to say was:
Encryption strength depends on the secrecy of the key, not the algorithm.
Re:Not Mutually Exclusive (Score:4, Informative)
DRM depends on proprietary software. You are encrypting a file, then giving the user the key to decode it, while telling the program in question to decode the file, but only allow it to be used in one of a few ways (eg. display PDF, but don't print).
Such a system is untenable with proprietary software (just need to find the right memory address), and absolutely impossible with open source software, as you can simply remove the line in the program that tells it what actions not to allow. (See xpdf). With proprietary DRM systems, the companies just hope it's difficult enough to decipher the compiled code of the proprietary programs, that it takes a while before someone finds the right spots in memory to probe/change, and publishes the details... Then, they make trivial changes to the DRM system, and call it a new, "fixed" version that everyone should start using quickly (before someone figures it out).
The only thing DRM can do effectively, is to prevent the first opening of the file. After you send that first key (eg. via server), no matter what the DRM involved, the user can (trivially) strip the DRM off, and do whatever they want with the unencrypted file.
If that is what you want... I would suggest using public-key encryption to protect the file instead of a commercial "DRM" system. Either PGP or SSL (keys in combination with a password) can make absolutely sure only the intended recipient can make use of the file, even if others obtain copies of it. If you are expecting any more control over what others do with the file, you are simply denying reality.
Re:BBC (Score:4, Informative)
Except that there are non-BBC channels and you have to pay the tax even if you never watch a BBC channel.
To use a car analogy, this would be like having to pay a monthly fee to Ford for "car services" regardless of what brand your car is.
Re:Strange question (Score:5, Informative)
XOR encryption isn't weak. It's just extremely vulnerable to a plaintext attack. Where that isn't an issue (eg. one time pads), it's the best algorithm out there.
Re:Consultation: where? (Score:3, Informative)
The last one was here
http://www.ofcom.org.uk/tv/ifi/tvlicensing/enquiry/ofcom_bbc.pdf [ofcom.org.uk]
Not too sure what is actually going on with the second round yet.
Re:BBC (Score:5, Informative)
In USA you're already required to pay a tax to a corporation (unless you are happy to die early from a treatable disease) - and guess what, we pay less in the UK for our health coverage than most people pay in the USA.
Re:Strange question (Score:5, Informative)
...and that's the major reason for the industry to move us to HDMI.
*facepalm*
You've just confused HDMI with HDCP, as so many do. I hate DRM, too, but in this case, that would be like refusing to use DVDRs because commercial DVDs are sometimes DRM'd.
The only possibility is to use a dongle / smartcard (same thing, different name)
Different form factor too, and usually a different, less sinister use, but I'll give you that.
in the display and run the signal encrypted from disk to display.
And what would that accomplish? I'm sorry, but if I'm going to rip a movie, I'm not going to do it by trying to capture 1080p video from HDMI and compressing it down to something manageable -- not when it's already on the disc in beautiful h.264 or VC-1. Maybe if there was no other way, but there's always another way, which was part of the point of my post.
Encrypting the signal from the box to the display only pushes the problem either back to the box, or into the display. If it was actually encrypted from disk to display, that just means you've got the decryption hardware (and the keys) in the display instead of inside your blu-ray player (or TV box, whatever). I really don't see how the display is harder to open up and hack around in than any other box.
But that's not even what's done with HDCP -- it takes the video from the disc, decrypts it, decodes it, then re-encrypts it and sends it to the TV. This means that the video exists in an encoded but decrypted state at some point inside the machine (set-top box, blu-ray player, whatever), and it's always possible (though it may be difficult) to retrieve a perfect-quality copy.
But all of this is offtopic, because, again, you're confusing HDCP, which is the DRM-over-video-cable scheme, with HDMI, which is a perfectly reasonable standard.
I'm running 2000+ x 1600+ on my old EIZO CRT monitor @85Hz on old analog VGA connector, HiRes graphics do not need HDMI
That is true, but after using an LCD screen, you couldn't force me to go back to analog, even 85hz analog. Once you've gone digital, VGA makes no sense -- you're taking the digital signal from the computer, sending it analog over the wire, for the monitor to make digital again before it can be displayed?
No, DVI solves that problem -- the image is sent, still digital, over the wire. And you don't hear Slashdotters whining about DVI being evil and DRM'd.
The point is, HDMI is DVI plus an audio signal. That's it. In fact, HDCP works just as well over DVI.
Now, I use a laptop as my primary computer. I have a nice 1920x1080 24" LCD on my desk. Every time I bring the laptop in there, I want to plug it in. Should I have to fiddle with all those pins and screws of VGA or DVI? Or can I just plug in that one HDMI plug? That goes doubly if you're using it for audio -- while my laptop isn't configured this way, in theory, I could plug the HDMI cable into a home theater system and have the surround sound system and the gigantic projector instantly supported.
The only real reason not to use HDMI for a new system is if you're using analog for some perverse reason, or if you're using DisplayPort instead (which is better).
Re:make the license fee voluntary (Score:3, Informative)
And if you watch TV without subscribing, you will be hauled before a magistrate, fined, and maybe imprisoned. People are imprisoned all the time for doing this.
Sorry, but that's bollocks. The maximum penalty is a fine of £1000 + costs. You may go to prison for not paying the fine, but that's the same for any offence. No one has been sent to prison for not paying their TV licence.
Re:BBC (Score:3, Informative)
Not all of the licence fee goes to the BBC, the vast majority does yes but some of it also goes to the other main channels.
The exceptions (where XOR is strong) (Score:4, Informative)
For example, XOR encryption is remarkably weak in most cases.
That really depends.
If you repeat a password cyclically ("hunter2hunter2hunter2...") and XOR it onto your plain text, you're doing a polyalphabetic substitution cipher. Those were broken around the first world war (IIRC); google for "Kasiski Test" and others.
If you use a random byte (independent of every other byte) at each position of the key stream ("%Nb2a#!\nF..."), XOR is the perfect cipher. By observing the cipher text, you have no better idea about what the plain text is compared to what idea you would have if all you knew was that the plain text was there*.
If you use a block cipher (DES, AES, etc.) to encrypt "n+0", "n+1", "n+2", etc., for some random initial offset n, and concatenate the byte blocks of encrypted numbers, you have in some sense a simulation of the perfect XOR encryption; if the block cipher is strong, this is strong as well (maybe if the block cipher can be broken in O(t), this can be broken in O(sqrt(t)), but if t is superpolynomial, so is sqrt(t)). [This is known as "Counter Mode", and you can use it to protect your ssh sessions. It has a bunch of nice properties compared to other Modes Of Operation, but that's beyond today's cryptography lecture.]
* Say we have a residents meeting at my dorm, and someone suggests we buy a Wii for our basement lounge. Later, I see an encrypted message between the dorm chairman and SomeWiiShop.dk. I know my dorm chairman is not a gamer, so my natural assumption is that she's acting on the request for a Wii. Since I also know about the applications of cryptography (for transactions in e-trade, but not the shopping pages), I assume she's bought a Wii (plus maybe some games and controllers). This is all without decryption. The "perfect security" of XOR is saying that I can't improve my guess by trying to decrypt---not that I can't have a good guess before trying to decrypt.
DRM *is* security through obscurity (Score:3, Informative)
the only even-more-half-assed solution they can think of to make it hard to crack the DRM is security-through-obscurity.
But... but...
DRM is security by obscurity.
Here's how DRM works: I encrypt the movie, such that a given key k is required to decrypt it. To play the movie, you need to decrypt it first.
Then, I give you the key. I don't want you to decrypt-and-save, or decrypt-and-share-with-your-6-billion-best-friends, but I want you to decrypt-and-play.
This "works" by putting a "Play" button in the playback software which does the decrypt-and-play, and not putting in a "Save" button which does the decrypt-and-save.
But if you run the program step-by-step in a debugger (which is boring and laborious and takes some background knowledge, but is a skill every competent programmer should have), you can see exactly how the program does the "decrypt-and-" part. Then you can write your own tool which adds "save" to the "decrypt-and-" bit.
Your only defence against someone using a debugger is hiding the key, using the key, and manipulating the decrypted data in ways that are too complex and confusing for the people using the debugger to understand. The name for doing that is `obscurity'.