Texture/Prim copy-protection via Encrypting 3D Cards

But like all "analog duplication" processes this will have nowhere near the quality or precision of the original object. It will have defects introduced by the process that require as much tweaking and editing as may have been required to even produce the original in-world object.

Usage of primitives is not likely to go away. It saves a ton of bandwidth vs raw meshes so prims are not likely to be going away anytime soon. I'd like to see how long it takes for an automated program to take this "fudged photo-generated mesh" and return it back to its original primitives.

This may well be extremely difficult. considering that the photo-mesh may be distorted in various odd ways that mean it does not sharply define any given shape that can be easily post-processed back into perfectly shaped prims.

Meanwhile, what may have been one texture spanning a flat prim with spikes protruding from it becomes 50+ texture fragments, none of which can be sewn back together to perfectly match the original due to distortions and breaks between each fragment around each spike.

And so the photo-mesh output might be usable in a full-fledged editor like Maya but actually getting it inside a virtual world in a usable low-prim state may not be possible, without simply just starting over from scratch and rebuilding it by hand.

scalar you really believe that by putting a vault in someone's home you defeat their ability to crack it open and look at what is inside?

- There is no such thing as perfect protection. With sufficient time any encryption can be broken. The point is to make breaking or bypassing it as difficult and complicated as possible, while making the mechanism transparent to the end-user.

With HDCP there really isn't much of anything required of the user. If the monitor supports HDCP and so does the video card, then it just works and they may not even realize that the High-Definition Copy Protection system is being used. Only people trying to sniff off a copy of the data for their own recording will run into the barriers of the protection system.


- Those who can break such systems will require an inordinate amount of time, money, and experience to gain access, which greatly limits the number of people who can do it in the first place.

Yes, reverse-engineering of chips does occur. It is possible to remove any silicon from its plastic shell, and examine it with an electron-microscope. But, the number of people who possess such microscopes is extremely small, and they are not likely to put their jobs/business on the line by exposing the trade secrets of entire industries..


- Using unique keys and multiple possible types of encryption on each 3D card makes a widespread decryption hack difficult, since brute-forcing your own card only gains access for you. It cannot be shared with anyone else for their card with its own unique keys.

soo what you suggest is turning sl in a cumbersome paranoid shielded system , consider every user as a potential thief and implement a drm system that will be cracked in 1 month if not less considering the amount of tech savy peoples in sl.

Personally i would participate to tear it open just to protest agains the concept.

result, earned "some" time, lost a lot of money and lots of potential bugs.

No lessons learned with the copy protection cds that can't run on some specific configurations?



Keep It Simple Stupid , we have laws to protect us , we don't need any DRM dictatorship, itsnot because you are willing to give up control on your system that everybody does.

BTW nvidia and ati are selling graphic cards, not hardware locks, theyr goal is to compete eachother to sell graphic cards to compete they need performant cards.

This is patently and provably false.



This is patently and provably true.



This would make SL unplayable, as nearly everything in SL would fall into the "Access denied" category. In order to view a texture, you must be permitted to download it. Once it's downloaded, there is no way to control its usage after that.

I'm still trying to figure out how the client renders a texture properly without ever knowing what the texture is (i.e. it's always encrypted).



How so very wrong.
A texture is a 2 dimmentional bit mapped image (or any other image format) which has a mesh mapped onto it so that the renderer knows which parts of the image go in the place of which polygons.
Looks something like this:
http://accad.osu.edu/~pgerstma/class/vnv/examples/texturing/yuvies/uvMesh.gif
That's the flattened mesh, the texture that would go onto it is painted in to look right, then UV mapped onto the object.
Hm, looks something like this:
http://accad.osu.edu/~pgerstma/class/vnv/examples/texturing/sarge_map.jpg

It is a given fact that as CPU power increases, the strength of a given key length slowly decreases. Which is why I'm saying the card should include a range of keys from 64 on up to say 4096. The high end keys might not be touched for years, until processing power increases demand a dropping of the old liability and moving up to a greater strength.

So go ahead, crack the 128-bit key. Once the crack has been publicized the 128-bit is dropped as not strong enough, and we move up to using 192-bit keys keys as the bottom-level protection. Crack that, and we again advance the base-level protection to 256-bit, etc.

So we burn a big table of keys into the 3D card on up into what now seem like impossibly long lengths, so that when the time comes to retire an old, weak, and more-easily-cracked key-length, there are still better keys waiting to be utilized for protection.

(And for that multi-card key-sharing I mention, it won't share its key unless the slave card authenticates using some insanely huge key size that is confirmed as valid by an online certificate authority. So breaking down the door into the protected space with brute-force via a weak key does not mean you can steal the entire keyring too. You'd still need to brute-force the insane keylength signing certificate to get it to give you that.)


Completely different situation. That is an attempt to force copy-protection onto a nearly 20-yr old technology that has no support for DRM in the first place. So of course there are going to be problems trying to fudge it into working anyway.


And yet even now they are both being forced by the entertainment industry to include HDCP, for their cards to work with new HDTVs, whether they like it or not.

.

That means the GPU is wasting time executing linear procedural code (which it's not optimised for) instead of heaveily parallelized rendering code (which it is).

This further increases the difference in performance between the systems that implement strong DRM and those which don't.

and here is where i would tap the keys


you didn't try to break my "vault" image i noticed?

Steve Jobs has the answer to that. You know Steve, he's the guy who's making a lot of money with low-quality DRM while everyone else in the business is losing money on high-quality DRM, because the consumers, the people who PAY the money, don't want DRM. Hell, they don't even want their OWN computers to be secure. The best thing you can do to keep your computer secure is - don't use Internet Explorer. Even if that's the only way to get to something online, don't do it. And people go ahead and use IE so they can watch a funny movie online. So... people who don't care about protecting themselves aren't going to spend MORE money to get a WORSE experience just to help protect the folks they're buying stuff from.

Anyway, here's Steve. I'll turn the show over to him.

That is not currently economically viable, the number of defective chips would make the entire process prohibitively expensive. The reason for having the components separate is to keep fatal component flaws from compounding. The chances of a single bit being bad in a multi-gigabyte on-die cache is not something to ignore. Not to mention that the die would be huge. The larger the die, the fewer you can fit on a single silicon disk; it all translates into manufacturing cost. The industry would refuse to build this on costs alone.



And what protects that bit of code? At some point data has to be decrypted to run. In this case you can't have a chicken & an egg and not have one come first. You must at some point have unencrypted data. How will the computer know what to do with the encrypted data? How will it be able to identify what decryption algorithm to use? If everything is encrypted, all it can try to do is to use brute force; and thats just to run the application.

Making a secure system is like trying to make an idiot proof system. They keep making better idiots.

I'm thinking this is a honey pot.

Actually the more I think about it, the more I see that key sharing is unnecessary, if the client cache can be made highly efficient.

If you want to run two cards in parallel, they BOTH autheticate to the SL asset servers, and when data is downloaded they each are sent their own independent encrypted copy of the data to be displayed.

This doubles the cache size and the bandwidth usage, but if the caching can be made efficient it's not really a big deal. And besides, for those who are willing to shell out big bucks for a dual-card setup probably wouldn't see a doubling in their cache storage as being significant to them, and they probably already have a 6 meg broadband connection, so doubling the data rate isn't going to be noticeable to them. Companies like LL might have a fee for the extra bandwidth usage, or would limit the max bandwidth for such people.

The 3D card would have its own onboard DRM that is ultimately in charge of the encrpyting and decrypting and the key management. Virtual-worlds companies like LL would have a say in how it is implemented by various 3D card manufacturers, and then their software simply utilities the various tools the 3D card provides to their software.

So LL's internal prim-decoding software is sent into the 3D card in an encrypted form, authenticated and decrypted by the onboard DRM in the 3D card, and then the code is run inside the protected space managed by the card's onboard DRM.

More DRM crap
Just what we need

The problem with this is its 1. GPU and CPU intensive
2. All that extra overhead for the incresed data packet size and dealing with cypt/decrypt on a texture mutiplied by the multiple textures in a given scene, constantly changing, multiplied by how many users?

Im sorry.. this is not feasable with current standards, and will probably kick more users out of SL cuz their graphics card/computer cant handle all this CRAP.

-John