Legal P2P, part 3
Today I will write about how data would be protected...
This is something that might be fuzzier than the rest of the other topics. Let's just state something that might be obvious to some but not all.
When a particular user has access to data and to the key that locks this data, it's very hard to prevent that user from manipulating the data. This is a fundamental problem with DRM system.
Imagine you give someone a box that is locked. Can you just say "Don't unlock it" and feel confident the box won't be unlocked. How about if you left the key to the lock hidden in his house and said: "don't look for the key!". How effective would that be? It clearly wouldn’t be very secure. A few methods come to mind on how someone with the locked box and the key could circumvent the lock. One way would be to find the key. The other would be to pick the lock. There are others. The person could wait for you to come in the house and see where you take the hidden key from. Even more effective, the person could destroy the box to see what is inside, bypassing the lock in the process.
DRM systems suffer from the same problem. For audio, the bottom line is that you can always record the sound that comes out of your computer and re-encode it to make it a new unprotected file. This is the same as destroying the box. Yes, you might damage the contents, but at the end, you have the contents of the box.
The whole point though, is to discourage casual copying. Make life hard enough for most people that most people won’t care enough to go out of their way and “destroy the box”. My system would try to do the same; life would be hard enough for people that want to easily hack it yet would still be ultimately hackable. The reason why I am not that stressed is that at this moment, there are competing technologies that are clearly more suited for people that want to abuse the system.
My system would be in constant motion. I want to not only have a key within the system, but a bit like polymorphic viruses, I want the system to constantly be updating itself and the key to prevent casual abuse.
Files would be stored in a virtual drive. Inside my virtual drive, I would have data that would constantly be on the move. I wouldn’t store the stream in a big file with a known extension. Instead I would constantly change the key and re-encrypt the system as a whole. Clearly I wouldn’t be able to change all the data all the time. What I would do is simply encrypt one block of a song and then move to the next song. This way, you always have a hole within the data stream. The keys would be stored across that large space. Hence, a person trying to hack the system would need to find the locations of those keys and would need to be constantly doing that because all files would have individual multiple encryption keys. I believe this would make the system hard enough to hack yet would keep all keys local, which is essential for a system that is not centralized.
This is something that might be fuzzier than the rest of the other topics. Let's just state something that might be obvious to some but not all.
When a particular user has access to data and to the key that locks this data, it's very hard to prevent that user from manipulating the data. This is a fundamental problem with DRM system.
Imagine you give someone a box that is locked. Can you just say "Don't unlock it" and feel confident the box won't be unlocked. How about if you left the key to the lock hidden in his house and said: "don't look for the key!". How effective would that be? It clearly wouldn’t be very secure. A few methods come to mind on how someone with the locked box and the key could circumvent the lock. One way would be to find the key. The other would be to pick the lock. There are others. The person could wait for you to come in the house and see where you take the hidden key from. Even more effective, the person could destroy the box to see what is inside, bypassing the lock in the process.
DRM systems suffer from the same problem. For audio, the bottom line is that you can always record the sound that comes out of your computer and re-encode it to make it a new unprotected file. This is the same as destroying the box. Yes, you might damage the contents, but at the end, you have the contents of the box.
The whole point though, is to discourage casual copying. Make life hard enough for most people that most people won’t care enough to go out of their way and “destroy the box”. My system would try to do the same; life would be hard enough for people that want to easily hack it yet would still be ultimately hackable. The reason why I am not that stressed is that at this moment, there are competing technologies that are clearly more suited for people that want to abuse the system.
My system would be in constant motion. I want to not only have a key within the system, but a bit like polymorphic viruses, I want the system to constantly be updating itself and the key to prevent casual abuse.
Files would be stored in a virtual drive. Inside my virtual drive, I would have data that would constantly be on the move. I wouldn’t store the stream in a big file with a known extension. Instead I would constantly change the key and re-encrypt the system as a whole. Clearly I wouldn’t be able to change all the data all the time. What I would do is simply encrypt one block of a song and then move to the next song. This way, you always have a hole within the data stream. The keys would be stored across that large space. Hence, a person trying to hack the system would need to find the locations of those keys and would need to be constantly doing that because all files would have individual multiple encryption keys. I believe this would make the system hard enough to hack yet would keep all keys local, which is essential for a system that is not centralized.
posted by PC @ 9:04 AM
0 Comments:
Post a Comment
<< Home