Suppressing The Concerns Over HDCP Content Protection For Intel's Linux DRM Driver

[shmerl]

as such users shouldn't have much to worry about with restricting their Linux systems.

I'm not sure about that. Anything that's touching DMCA-1201 and similar garbage is already toxic. I.e. even if it's not running, but you are modifying it which potentially can affect DRM, it can kick in anti-circumvention laws. So I'd say it simply should have no place in any upstream project.

[shmerl]

Like all encryption HDCP is not an inherently bad idea.

Compare a lock you put on your door to keep strangers out, and lock someone puts on your cell to keep you in. It's same lock, but purpose is quite different. Encryption can be used for your security, and it can be used to compromise it, by obscuring malicious code that runs on your system.

The main problem of DRM is its intent. Its very premise is privacy breaching preemptive policing based on presumption of guilt. So in its essence it's overreaching and therefore unethical. Same you'd find unethical if police would monitor or restrict your every move by default "just in case" you decide to do something illegal.

[Guest]

Digital Restrictions Management (DRM) - provides heavy protections for other people's content from you, by restricting your freedom and ability to use your computer (e.g preventing screenshots, desktop video recording, mangling clipboard contents). The hardware also participates in this - preventing you from using non-DRM but otherwise perfectly good hardware for display (e.g non-HDCP display cable, monitor that doesn't support HDCP) when displaying DRM content. So yeah, fuck DRM.

I totally support securing display of my personal items - personal photos, videos and documents.

The thing is, commercial video like movies and TV shows are provided way more protection and security than your own photos, videos and documents - that's messed up.

[JPerez]

In my work we use HDCP to display content to our customers. we own the infrastructure and we need to stop users from pirating our stuff.

This being in mainline and not out of tree is a good thing for us

Sorry if I sound a bit harsh, but the effort your team is being spared, is pushed at least 2 times over the heads of the community developers that makes that infraestructure your company is using, they have to test and debug code they didn't do and know nothing about, is obvious they only trust what they do; Ask yourself what would you do if you were in a community project and have to support something that you didn't do and know nothing about?.

There could be another way to do this, companies that secret code inside drivers, browsers or other community developed programs could fork and mantain their own versions so they can actually control their platforms, test and provide better products in a smaller time; Also is a good way to control people getting access to those blobs and non customers don't have to deal with unwanted software (Like when I found out that my Windows10 laptop was wasting network bandwith, hard disk space and CPU distributing updates to other computers in the network).

Also, this:

https://tech.slashdot.org/story/13/05/11/1430259/microsoft-developer-explains-why-windows-kernel-development-falls-behind

[Luke]

In my work we use HDCP to display content to our customers. we own the infrastructure and we need to stop users from pirating our stuff.

This being in mainline and not out of tree is a good thing for us

I make a point of not being one of your customers, nor one of any of the other sellers of paid and DRM'ed media. I don't know what part of "the infrastructurer" you claim to own, but you do not own our computers and only own some of the ISP's at most. Since you do not own and did not pay for my hardware, I don't owe you anything in terms of controlling it and am free to avoid both hardware and software that deny me control of m own property.

That said (as I said on another post), if you write code you use for DRM that I have another use for (e.g. disabling screenshots by malware while encrypted chat, encrypted email, or sensitive video editing is going on), and that code is released under the GPL or a similar license I won't hesistate put it to this alternate use.

DRM itself has both the "too many users in the group" problem and also often to "too few possible keys in use" problem at some level to really secure anything, unless your objective is limited to getting a couple weeks of lead time before your product goes to bittorrent. I will bring back the example of distributing a pre-release copy of a movie to reviewers without it ending up on bittorrent. I could insist each reviewer use my PGP key to send me a 35 random character passphrase, and send (online or sneakernet, it makes no difference), a disk image with a LUKS encrypted volume containing BOTH the OS and the video file to watch. That's about as secure as it gets-except any crooked reviewer still has their copy of the key plus everything encrypted with it.

OK, so you provide the key yourself, and find some way to send it encrypted and hide it from the user, and still have a different key for every user. The machine still had to run to use the key, and some piece of hardware has to have the decrypted key in some kind of memory or register. Even hardware curtained RAM etc would only slow this down. Possible attacks include things like altering signed binaries and/or signed drivers after they have been loaded, plain old buffer overflows, hardware exploits, that sort of thing. Remember: posession=ROOT, and no computer can ever be simultaniously trusted by two mutually opposing parties.

You would have to provide the entire locked-down system plus a network that refuses all other connections (really own the infrastructure) and probably keep everything but the screen, mouse, and keyboard physically out of the user's home. Even then, the mouse and keyboard might be enough for root, with the end user effectively sitting at the console but all USB ports glued shut, etc.

[oiaohm]

In my work we use HDCP to display content to our customers. we own the infrastructure and we need to stop users from pirating our stuff. This being in mainline and not out of tree is a good thing for us

The reality this is the normal mistake HDCP really does not help with this. With HDCP 2.2 to 1.4 and 1.4 to CSI-2 the to a rasberypi what ever you send over HDCP can be decoded and captured. It really a false dream that HDCP helped protect content.

https://en.wikipedia.org/wiki/Van_Eck_phreaking

HDCP was at first design to deal with Van Eck phreaking. Now what would be ideal is if all password boxes and the like could be HDCP encrypted before going to monitor to protect against Van Eck phreaking.

Reality is all the HDCP 1.x stuff is cracked. HDCP up to 2.2 is breakable. Even in HDCP broken state the encryption it works against Van Eck phreaking attacks as radio monitoring to perform Van Eck Phreaking has to put up with radio noise so are missing bits of data. Those missing bits of data against a encrypted stream result in not being able to decode it.

You think about this boxie if HDCP had been done right with primary on defeating Van Eck phreaking attacks with little extras to make content coping harder there would be way less push back as then it would be providing something beneficial to all users.

Really I would love to be able to load up a virtual screen that support all version of HDCP so that I can make like login screen clients and test that they use HDCP correctly if it able to be used. Of course a virtual screen that allows capturing of out put for automated checking that stuff is working right is not going to be liked by those attempting to use HDCP for content protection as this would basically make HDCP as stream to end user for decoding,

Remember my interest is to close the Van Eck phreaking attack or at least make it insanely hard to pull off.

[oiaohm]

The reality is that encrypting video signal was in fact designed to defeat Van Eck phreaking. What is stupid here is hdcp is used for protect content but is not used for general content.

The reality is nasty hdcp even the broken forms like HDCP 1.4 work perfectly against attacks capturing radio signals. Now for automated application development a virtual screen that support HDCP would be great. So that applications developers can test that HDCP output option is in fact working correctly. This would not make those attempting to protect content happy.

The reality is those protecting content seam to fail to care about protecting there personal computer system security. We should want login screens and possible all content going across the monitor cable encrypted. So where with what google offers is there going to be the frameworks for HDCP to be used effectively by other applications where it suites correctly.

[madscientist159]

We should want login screens and possible all content going across the monitor cable encrypted. So where with what google offers is there going to be the frameworks for HDCP to be used effectively by other applications where it suites correctly.

Glad to see someone else thinking along these lines! The reality is, a signal encrypted by HDCP is basically unable to be remotely sniffed even if you did know the HDCP master keys simply due to how fragile the whole process is and the fact that RF radiation from the encoded data is not practically recoverable (high entropy, signal looks like white noise to the receiver) as compared to a raw, unencrypted VGA or DVI/HDMI stream.

It won't catch all interceptions by any stretch of the imagination, but it does make it a lot harder to snoop on the monitor signals without inserting some device in the line that can be found on visual inspection....

Best, of course, would be the ability to set up a key with your specific display devices ("pair" the monitors to the GPU, for lack of a better analogy). Even physical access to the monitor cable and/or monitor wouldn't yield snooping ability if this scheme was implemented correctly.

[oooverclocker]

I don't have any problem with HDCP as long as it doesn't introduce new binaries. When you create content you should be also free to decide who has access to it.
There might be people who use illegal ways to get access but I just don't use it when I have a problem with the DRM.

BTW, I have a way bigger problem with these Facebook and Twitter buttons. Firstly, who uses Facebook, secondly I don't think it's a good idea to support Twitter either though there are people using it that are not bots. I'm usually very strict about social networks not existing in my life and I don't know whether I can use services that mention them next to every post.

[caligula]

I don't get your argument, this has nothing to do with patents or getting sued.

You previously said

I've never understood the unflinching purism people have when it comes to open source and stripping out everything not "libre in spirit".

Free software strips out things like mp3/aac/h264 support for legal reasons related to patents. Even if you had the license to use them in any possible way, if you give your friend a file in proprietary file format, he/she faces the same issues with patents. You might have a more limited set of codecs and stuff in the free world, but at least you can't come up with data which can't be consumed or modified according to free software philosophy. If you support proprietary formats, they'll become more popular which hurts both open source and free software.