as such users shouldn't have much to worry about with restricting their Linux systems.
Announcement
Collapse
No announcement yet.
Suppressing The Concerns Over HDCP Content Protection For Intel's Linux DRM Driver
Collapse
X
-
- Likes 7
-
Originally posted by boxie View PostLike all encryption HDCP is not an inherently bad idea.
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.Last edited by shmerl; 04 December 2017, 11:48 PM.
- Likes 16
Comment
-
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.
- Likes 9
Comment
-
Originally posted by boxie View Post
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
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:
New submitter mha writes "In a response that truly seems to be from a core Microsoft developer, we are told about why Windows kernel development continues to fall further and further behind that of the Linux kernel. He says, 'The cause of the problem is social. There's almost none of the improvement...
Last edited by JPerez; 05 December 2017, 12:11 AM.
- Likes 4
Comment
-
Originally posted by boxie View Post
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
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.
- Likes 5
Comment
-
Originally posted by boxie View PostIn 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
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.
Comment
-
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.
- Likes 5
Comment
-
Originally posted by oiaohm View PostWe 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.
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.Last edited by madscientist159; 05 December 2017, 01:56 AM.
- Likes 3
Comment
-
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.
- Likes 1
Comment
-
Originally posted by Kver View Post
I don't get your argument, this has nothing to do with patents or getting sued.
I've never understood the unflinching purism people have when it comes to open source and stripping out everything not "libre in spirit".
- Likes 3
Comment
Comment