Texture/Prim copy-protection via Encrypting 3D Cards

Summary:

There is a way that data streamed to each client could be protected from copying by a packet-monitoring program such as the CopyBot, or a cache data-extraction tool.

However, this is a complex solution which would require the help of all 3D card manufacturers, to create a secure end-to-end encryption channel that protects data all the way from LL to the point where it is sent into the 3D card and decoded.


Using Public/Private Key-Pairs to Protect Data

Encryption can work if the graphics card incorporates a secure internal texture cache and has a strong private certificate burned into its core by the hardware manufacturer, where the key and memory cache is completely inaccessible to hackers and programmers.

Such a card could be told to report its public key, which would be sent by the client to the asset server at LL. There the asset server would encrypt the data before sending it to the client, and would sit in the cache in its encrypted form.

When needed the encrypted texture is passed to the 3D card, which internally decodes and caches the texture in a memory space not accessible to programmers. It then displays the texture using the internally decoded data.


Encryption of Meshes and Prims

Meshes could also be similarly encrypted at LL with the 3D-card's public key, and sent to the client in encrypted form, though this would potentially destroy the bandwidth-conserving features of LL's prim-based world.

It could be worked around, if it were possible for the graphics card to be passed code by the SL Client telling it how to extract prim-based data into full meshes.

This way the object shape data could still be stored as bandwidth-saving encrypted-prims, which the 3D card would internally decode and then turn into full meshes with LL's extrapolation code to drive it, and all within the secure and inaccessible protected-memory space inside the 3D card.


Data Protection from Protocol Wrappers

Such a system would be immune to "texture/mesh ripping" by protocol wrappers like GL-Intercept, since the decoded texture data never leaves the 3D card. The wrapper would only be able to see the encrypted texture, mesh, or primitive data being sent into the card. Without access to the 3D card's internal private decryption key, the protocol wrapper would not be able to extract any useful data.


Multiple key types, Multiple levels of protection:

Taking this brainstorm to its fullest degree, a 3D card could be burned-in with a whole table of unique public/private keys, each using different algorithms as a hedge against cracking efforts, and each type with varying strengths from 64-bit on up to 4096-bit.

This way LL could tell the 3D card to pick a key type and strength based on what the content creator is willing to pay to protect their content.

Much stronger key strengths could slow down the 3D card and LL's asset farm due to longer encryption/decryption processes, so to offset and limit the use of very strong keys, LL might charge an extra L$100 premium for 128-bit encryption, an extra L$1000 for 512-bit encryption, L$5000 for 1024-bit, etc, per each uploaded and protected prim or texture.

Objects designated as Free to copy / Free to modify by anyone would not need to use any encryption, and so would just be charged the traditional L$10 to upload.


Impact of Encryption on a robust cache

Encryption of the cache is compatible with some of the other speed ideas I've mentioned elsewhere, such as multiple individual regional/sim caches that duplicate cache objects using filesystem hard-linking for speed of finding and accessing.

Since all objects in a duplcated-region cache are all encrypted for the same 3D card in your computer, they would all be equally decodable by your graphics card however they may be duplicated in the cache.

Changing out your 3D card for a new one would mean a loss of the private keys burned into the card. You would either be forced to delete the entire cache so it can be regenerated again for the new 3D card, or the LL client would need to sweep through the cache and remove any old encrypted data for the previous 3D card.


Dual/Multi-card 3D Encryption:

Dual-card (SLI/Crossfire) 3D encryption could work. But to do it, one of the cards would need to share its private key with the other card before they could both access the data:

1. Slave sends its 4096-bit public key to Master.
2. Master checks the signing to verify that the encryption was issued by the manufacturer and is not a masquerade attack
3. Master encrypts its private key with the Slave's public key
4. Master sends the encoded data to the Slave
5. Slave decodes the data using its private key and stores the master's key in its cache.


Industry Support Absolutely Necessary

So, an encryption system CAN work, but it requires a completely different sort of 3D graphics card, with built-in encryption and memory-protection features not in any card currently available.

All of this would require some strong participation by ATI and nVidia to put such encryption/decryption features into their 3D cards.

For this to work, all users of the virtual world would have to be required to use 3D cards that have encryption methods built into them, much like the encryption used by DVD players and the new High Definition Copy Protection (HDCP) system. Existing 3D cards without any built-in encryption features could not be permitted to use the virtual world since they would have to be able to access the protected data free and clear to work properly.

I don't think the virtual-worlds market is large enough yet for video card manufacturers to be willing to devote significant effort into developing internal 3D encryption/protection methods, but eventually as the market grows it could be included as a standard feature available for use by any virtual streamed-environment that wants to use it.


.

Second Life Ideally Suited to Phasing-In 3D-Card Encryption

LL's concept of separate sims and grids makes this environment ideally suited to slowly phasing in support for 3D-card encryption. There could easily be a separate fledgling grid just for encrypted assets and environments, that exists alongside the current main grid.

If such a grid were available, advertisers and large media corporations seeking to protect their assets would likely flock to it, and it could slowly grow sim by sim, until it is as large or larger than the current unprotected grid.

Unique Keys For Each 3D Card

Unlike a DVD Player, a 3D card need not be limited to a single universal encryption key that is shared across millions of devices. The downfall of DVD protection is that all DVD manufacturers must utilize the same encryption key for all DVD players to be able to decode the same data. Since there can be no communication between the DVD player and the DVD disc manufacturer, it is not possible for a DVD to be uniquely encoded to only work on one specific DVD player.

But for an encrypting 3D card operating in an online environment, it is able to send its own public key to the servers of the virtual world, which allows the asset server to uniquely encode asset data that is specific to the private key of that one single 3D card.


Each 3D card is therefore able to have its own completely unique private encryption keys that do not have a common-mode decryption method that coincides with any other card.

Using unique keys that do not share a common-mode decryption method would require a PROM in each GPU that is burned one time only, at the manufacturer's chip fab plant.

.

What happens when you're running SL in a window? Particularly on an OS that depends on compositing in the GPU for performance, like OS X? What do you do about code-injection in the SL client? What do you do about the upcoming AMD/ATI "fusion" combined GPU and CPU?

The economics alone make this a fantasy situation, but just to play along why wouldn't someone just modify the firmware of a random card to hand over it's private key? Or insert a rogue piece of hardware claiming to be a secondary card in an SLI setup?

The economics of the situation mean that this is not CURRENTLY financially feasible, but if virtual worlds continue to grow in popularity, eventually this will be feasible.

Who says the GPU firmware has to be something that can be erased and rewritten? That is a convenience that does not need to be provided. And besides, when was the last time you ever uploaded new firmware to a 3D card's GPU? I've never seen it.

Ceritificate signing can be used to prevent rogue hardware from masquerading as a 2nd 3D card. If the master 3D card sees that the signing is invalid when checked against the card manufacturer's online certificate authority, then key passing will not be permitted.

If the certificate authority cannot be reached because you are not connected to the Internet, then key passing will be denied. Besides if you're offline then you're probably not using an online virtual world that needs to use cross-card encryption, are you?

scalar tardis, you do realise that everything that is on a thrid party system cannot be secured right? being hardware or software, it doesn't matter how hard you bang your head on it.

Ever heard of modchips?

Its not easier to prevent the insertion of copys into SL?

If i get the data of an Object, i must somehow insert it into SL again. I must feign, that i created the object step by step. That I'm the owner.

Perhaps this way can easier be made save.
Textures and scripts cant be protected. But the process of creation an object is handwork.

PS: In Germany, there is now a lot of press news and a lot of people going to try SL. The lag and server load will grow rapidly. Better cache system should have first priority.

Modchips only work where the hardware designer is careless and allows critical logic to be exposed as traces on the circuit board that can be probed, monitored, and injected with external signals.

Simple electronic security systems generally reduce down into one single pass/fail verification path that spans several chips on a bare circuit trace. Modchips work by injecting a false signal into the exposed trace that constantly says "PASS! PASS! PASS!" and the system mistakes that for its own test result.

Modchips do not work where the circuit designer is careful to put all their test, verification, and decoding logic all within one single chip, where there are no exposed circuit paths to exploit.

To protect the memory subsystem from probing and injection, it might be necessary to use a monolithic design where the GPU and protected memory are integrated together.

Scalar: you haven't answered my question. What about integrated CPU/GPUs like AMD's "Fusion" project? What about operating systems that require access to the GPU for more than one program?

I do not claim to be an electronics engineer, but once again as with firmware flashing Eddy mentions, there's no reason that this HAS to be integrated with anything else. That is just a convenience intended to drive down costs in an EXISTING, well-established technology.

New technologies are often used in isolation before it can be determined how it can be used together with anything else, such as the original Voodoo 3D card that stood alone in a PCI slot and used a VGA pass-through cable, and the current PhysiX card that also stands alone in a PCI slot. Eventually it all can get integrated and merged after several development cycles.

A secured GPU might very well be forced to be separate from the main CPU at least for the initial realease, and have a separate memory space permanently dedicated to holding encrypted textures and surface data, alongside the GPU's regular unsecured video memory.

Later iterations of the hardware might only have the secured memory space onboard and can utilize shared motherboard memory for the unsecured video.



The output framebuffers need not be protected and can be in a common memory space for compositing with other onscreen application windows. The output framebuffer can't really be protected anyway since it can be captured via printscreen or just by photographing the screen with a physical camera.

The main protection here is for the full, raw texturing data not yet applied and cut by a polygonal surface and modifed with world lighting, distortion, fog, etc, and for protecting the precise 3D shapes and designs of the prims/meshes themselves.

well i am sorry but personally i won't buy hardware i haven't total control, it isn't because there is a few criminals out there that everybody has to get a tracking chip under the skin

1) Object Encryption & Compression: 10 -> 20
2) Protocol Encryption: 2 -> 4
3) Encrypting the cache: 2 -> 6

Multiply those all together and you get 40 to 240 more processing time. Mores Law states that processing power doubles every 18 months. Which becomes 8 to 12 years. Considering that LL supports hardware five years old, that becomes 13 to 17 years before it will become a requirement. Nobody thinks that far ahead in the computer industry. In this area of the computer industry it's possible to be at the top of the heap and go bankrupt in 18 months.

Texture theft is inevitable. The client has to be able to request textures. To request textures it has to be able to get the UUID's from the object information. These UUID's could be sniffed out. Protocol encryption doesn't really solve this problem as then the user can reverse engineer it. If you have the UUID you can reuse it in a build.

Memory has to be readable. You can't render encrypted data, it's not possible. The GPU has to have unencrypted data to work with. This means the GPU and its dedicated memory is open to attack. All the user need do is attach directly to the memory chip. Classic mod chips are to get around security and enable features. This just needs to snoop in on data transfers.

Recently there has been research into taking pictures and generating 3D models from them. I came across one set of research that worked from a single picture. Microsoft has taken a different approach and uses multiple pictures (linky). With software like this, you could take a few pictures of an in world object, and build a mesh that accurately represented it. I assure you, software that can do this will be freely available long before your Ultra Trusted Computing hardware comes out.

The cost of the technology has to get down to somewhere near the level of the existing established technology before there's enough of a market for something like SL to treat it as a requirement, so there has to be a compelling application that absolutely requires it *outside of* niche applications like 3d VR before it will ever be practical to use here.

The push-back against DRM is enormous. Just ask Sony. That makes two huge hurdles for this kind of technology to jump before it can become a mass-market product that SL or any competitor can reasonably require. You can't ignore the cost of the product in your scenario.

Which brings up a second point: the mapping from prims to meshes doesn't happen in the video card, it happens in the main CPU in the SL client application.

Nope, to make this practical it can't be more than a couple of binary orders of magnitude overhead, otherwise you're going to have people looking at something that's like SL today and comparing it to something that's like SL or its descendants will be 13 years from now.

It would be like trying to outcompete SL today with the state of the art in 1993. Think about what the "state of the art" for the Internet was 13 years ago. Would you pay US$10.00 for a "skin texture" you could apply to a paper-doll overlay for a 2d 256 color GIF avatar in an internet chat room using NCSA Mosaic?

Once again, we have a radical, unworkable suggestion for the protection of content made by someone who has not done proper research into the problem.

It is impossible to restrict the ability of software to programmatically read graphics buffers from the video card - most modern operating systems depend on this ability in order to maintain windowed graphical user interfaces.

The magic words here are "a graphics storage area on the video card inaccessible to programmers". By definition, in order to be usable at all, every piece of functionality on a video card, and all of its display memory, must be accessible to programmers. There isn't a single computer game or graphical application ever written that doesn't depend on this ability. What you're asking for may be technically possible, but is so hopelessly impractical that no software would be written for it, and so economically impractical that no technology company would fund its development. History has shown time and time again that customers will not pay to have rights they currently have taken away.

In addition to this, you've gotten one of your basic facts wrong - CopyBot does not "intercept packets". It's not something that is inserted between the SL servers and clients. It is a complete, standalone client. Moreover, it doesn't even have a graphical interface. There's no display at all of what the CopyBot is looking at, no view of the world. The CopyBot does not need to see the bitmaps in order to copy them, so this entire discussion is not only pointless, it actually does the community damage by spreading the preposterous notion that such a thing is actually a viable possibility, thereby wasting the time and energy of a great many people whose time would be better spent in more fruitful pursuits.

FurCadia anyone?
Prices on Dragon Avatars (and that's US$ listed)

The point is, the SL content servers don't encrypt anything because they can't, as the data pathways are built now.



Yet, how very odd that encryption, certificate authorities, and data security are already in use on websites to protect textures (called pictures) and HTML (could be prims). All encrypted live on-the-fly by the webservers and similarly decrypted on-the-fly by client browsers, all without a similarly apparant 40-240 times greater processing power over normal unprotected HTML. How is this possible?



Must the memory be separate from the GPU, on entirely separate silicon interconnected with traces? Build the memory circuits right into the GPU itself and there's no need for any connecting wires to be hacked in between them.



In time, this won't be a choice you can make. When environments like SL go truly mainstream, content producers with millions in assets at stake will demand it and scream for it from both nVideo and ATI, and it will be something that cannot be bypassed or disabled.

Do you know what HDCP is? You might be in for a suprise if you go out and buy a new HDTV and try to connect your old video card to it via HDMI. In time it will not be possible to buy a video card or an HDTV that does not require HDCP, as forced on the hardware manufacturers by the enternainment industry.



To the programmers who create the virtual environment, yes. So you don't think those programmers whose code needs to be inside the protected space couldn't have their driving code also be protected with the same security that their own asset servers are using?

When running in encrypted mode, the GPU might not permit any data to enter the protected space (textures, meshes, or code) unless it all is encrypted with the same signatures. For the virtual-world company, those signatures are readily usable for their incoming driving code, just as it is for their incoming assets.

Due to features like hardware texture and lighting, it is completely unnecessary for an unprotected CPU to handle such details, and the GPU can do a much better job by itself. The main CPU need not have direct involvement any of the texture/mesh/lighting/environment processingl, except as a director saying "go here, do this" and managing other details like feeding in more encrypted data to be used in the protected environment.

.

You're missing the point. Doesn't matter what LL adds to the client, copyBot still gets around it BECAUSE ITS A CLIENT TOO!

With this protection model, the virtual world company's OWN client has as little access to the encrypted material as a 3rd party client would.

The only data either client can get unprotected from the asset servers, is the data for which you have permissions to modify and the server sends to you so that you can edit it.

Everything else is purposely outside the reach of even the company's own client since they cannot trust it (process monitoring, bytecode editing, etc).

Textures cannot exist independent of a mesh. It is impossible to show a texture without a mesh on which to display it. Once a mesh is protected, the textures can all be issued new keys, independent of the original unprotected form, and will not be reported to objects outside the zone of protection.


The current texture access model of "know a key and you can use it" is severely flawed. Why is there not some permission system, to say who can or cannot use a texture?

If you're not on the group or user access list for a given texture, you or your objects should be denied access to the texture, encrypted or not.

If you don't have proper rights, the asset server should either give an error response or just send you a generic "Access Denied" texture in its place.

.

You're confusing two completely different systems with radically different goals and requirements.

SSL does a very minimum of encryption, and it *only* does it bewteen the applications. The difference between that and maintaining the data in encrypted format while you're operating on it is like the difference between buying a beer in a bottle and building a ship in a bottle.

In the web example, you're protecting something that both participants in the transaction want to protect. The person running the computer has no incentive to break the system. He *wants* it to stay secure... so he can actually know the keys used to protect it, and efficient private-key algorithms can be used.

In the DRM example, you're protectng something that only one end of teh transaction wants to protect. The person running the computer has no incentive to protect the system, he wants to break it... so you have to hide the keys from him and keep the content protected every instant it's not being used.

So... if protecting a chunk of data increases the cost of moving the data from one point to another by 240 times, that's irrelevant. It's only paid once, no matter how many times the web page is read by the browser, no matter how many times an image is displayed. The images are all sitting there in your cache, unprotected, because you're not trying to "crack" them. It takes 2.4 milliseconds to copy the web page from your network card to cache, instead of 10 microseconds... who cares?

But if it has to pay that cost EVERY TIME the object is referenced... then the 240 times *does* matter. Now it takes 2.4 milliseconds instead of 10 microseconds every time you load the texture, every time occlusion culling hides or exposes it. And there's *hundreds* of textures... so instead of that copying taking 2 milliseconds every frame, it's taking 9/10ths of a second. What's THAT going to do to your frame rate?

And nobody will buy it. Sony owned the music player industry, and they refused to make music players that could play anything but encrypted Atrac files. Creative and (of course) Apple made music players that did what customers wanted. Apple even ran a "Rip, Mix, Burn" advertising campaign that thumbed their noses at the industry. Apple's DRM in iTunes is basically "honor system" compared to what Microsoft provides... but who's actually making money in the business now? Who's got the market share?
And (as I already pointed out) that data includes the unencrypted prims, because the conversion of prims to meshes is done by the CPU.

And that data includes the unencrypted prims, because the conversion of prims to meshes is done by the CPU.

And as I've already pointed out, the GPU is perfectly well capable of being given a piece of code from the virtual-worlds company, wrapped with the same encryption as the meshes/textures, that tells the GPU how it can decode the prims into meshes without the involvement of the main CPU.

If LL were to want to add new code for new prim types, they just update this code that is run by the protected GPU inside its own safe address space.