securing your vert data? any way?

OpenGL Development JOGL Development
#1

Hi guys,

I’ve got a problem. I’ve made a JOGL applet that simply loads a model from an external file on a website. My problem is that i need some way to protect the model data, so that it can’t be ‘stolen’. Generally, people load the applet and then the applet streams the model from the server.

The ideas i’ve come up with were first serializing the arrays that contain the vert data, which would make the initial object file (which is normally just a big text list of the verts and faces) unreadable by your average person. I don’t know if de-serialization is possible without knowing what object types they belong to, but the object types could probably be established by de-compiling the class files and seeing which classes implement serializable, and i don’t know if any obfuscation could really hide that. I could also encrypt the file being streamed (because otherwise the bytes could be read out of the byte stream when the object is de-serialized), but again, if the classes were decompiled i assume the decryption process at the user-end could easily be compromised?

My main idea was to somehow serialize the compiled openGL lists and stream that, since even if compromised there’s not a lot someone could do with it to pull out the data to my knowledge. But of course, lists aren’t serializable and i don’t know of any way to store them for transfer.

My last idea was to essentially obfuscate the object itself, in a way that wouldn’t affect how it looked in openGL rendering but if retrieved into some 3rd party program would be incredibly messy and virtually unusable, but no real ideas on that.

If anyone could expand on any of these ideas or any other ideas at all, i’m all ears, cos at this point i’m clean out of ideas for stopping the display() data from potentially being compromised.

#2

You do realise that there are programs that are able to intercept all graphics calls and capture the model data on it’s way to the graphics card, right? You can implement as much crazy encryption from server to client but it’ll still easily be capturable in this way.

#3
  • agrees with Orangy Tang *

I wouldn’t start worrying until you have something that people actual use. Just leave it open for now and add it once your program starts to become successful.

#4

Typically yes I agree that the data is incredibly easy to intercept, but with the advent of shaders you could encrypt your vertex data before submitting it with a draw call then decrypt it in the vertex shader.

If you do manage to implement something like this I think you’d certainly have a Siggraph paper on your hands, as I’ve never heard of anything being done like this before.

#5

You can intercept the shader code too…

Any clientside security is just raising the bar.

#6

  1. All encryption schemes I know rely heavily on bit-wise operations (like add and xor) which aren’t available in shaders.

  2. As mentioned, shader code is also easily intercepted, so you’d have the code to decrypt the data easily. Obsfucation isn’t going to help due to the limited number of instructions and your input and output values would be obvious.

  3. All of the above is going to add hideous amounts of overhead and bring your framerate down to a crawl.

If you really, really need to protect your model data (and I can’t see why) then render it on the server and send an image to the client.

#7

No commercial game has ever encrypted their model data. Why should you need to? The most they have done is store the models in a custom format to prevent casual theft. If someone steals a model it is obvious anyway. If someone else tried to use the model they would get a quick lawsuit. Unless you build a game that becomes wildly popular, this is not even a concern. Then if it does become popular it is not a concern because everyone would know that they stole the model from you.

#8

On the ‘why would you want to’ front, assume i have a very good reason. This isn’t for a game, and it’s in the owner of the model’s (which won’t be me) interests for the object to be viewable but not interceptable.

This really rules out leaving it till later or not worrying about it, i’m afraid.

#9

There’s no way to secure data that you’ve distributed to the client that can’t be circumvented by a motivated adversary. Your options are:

  • Rely on copyright laws to prevent misuse of the data
  • Don’t distribute the data, and do as OrangyTang suggests
#10

seems like the only solution then is to do the rendering on your side and send the rendered image to their display. This way the model never leaves you and you are just sending them the view of the model.

#11

Open source implementations of encryption schemes usually have little issue with the source being visible, I imagine the same would be true for an intercepted vertex shader.

And from a cursory glance at the RSA algorithm and I don’t see the need for any bit-wise operators, just mod and pow.

Of course then all someone needs to do is run a software renderer they have access to the source code for and grab the vertices on their way to the rasterizer or triangle setup, :-. Yeah, there’s no way to stop your data from being stolen short of rendering server side like Z-Knight suggested.

#12

The algorithm being visible shouldn’t be a problem, but it’s not just the algorithm - it’s the algorithm, the data and the key too. You’re basically handing any interested person everything they need to decrypt the original data.

And mod is still a bitwise operation. I don’t think it’d be possible to emulate that (to the accuracy required) with the float-only operations available in a shader. You’d hit all sorts of rounding and precision problems.

#13

Yeh, that’s pretty much what i keep coming back to, but on face value, it seems totally unviable - for a start i’d need a server that can run java apps server-side, and then think of the amount of requests it’d need to be handling every time someone moved the scene if only a few people were using it, plus the delay on buffering the image stream. Meh. This is turning into an impossible situation. Maybe i should look at using Flash and it’s fake 3D.

Of course, even if someone did get the model data out, it’ be in triangles, which wouldn’t be much fun when trying to use in an app like Max or Maya, but no more than an inconvenience. I can’t think of any further ways of making it unworthwhile like that, and most ways of buggering up the model data would need to be reverse engineered client side to be displayed in JOGL so could be seen.

#14

What are you trying to do, exactly? Guessing and mind-reading aren’t terribly productive.

#15

If I’m correct, NCSoft encrypted their model data in Lineage II (standard UT2004 engine file format)… but still use GLIntercept or 3D Ripper DX and you get vertexs, textures and shaders…

#16

Alright, you guys are familiar with programs like 3D Studio Max, Maya, Lightwave, whatever, for making 3D models for CG artists. Let’s say you made a model in one of these programs and you wanted to sell it. So, you put the project file for sale, but all of these programs have the capability of exporting to a standard .obj representation of the model that just contains vert, normal and face data. The idea is then that JOGL can use the .obj so that someone could essentially preview the file they’re going to buy online in full 3D. While the viewer would never have access to the .max (or whatever) project file without buying, they would have access to the .obj via the online model viewer (not directly, but the general data would be there as we’ve discussed), which is a pretty good representation of the model, if not as good as having the project file.

#17

Personally I’d probably just go with a prerendered video of the model spinning on it’s axis, and maybe a couple of high-res images along side that. That gives you 99% of the information but leaves your data protected and should be relatively easy to implement. Plus it’ll be more compatible as pretty much all pcs can cope with a simple flash video player, but might not be able to run a jogl app at a decent framerate (or at all).

#18

Yeh that’s definitely a consideration. I’d gone to the lengths of using the JOGL applet loader so that people without JOGL installed can use it and all that, so it works on most PCs, and i was going to use various adaptive frame rates so as not to bog down PCs. It would have been a really nice gimmick, all in all, to be able to view a model completely. But i can’t really risk the data being compromised, even if its not the original data that would be paid for.

#19

Would something like Quicktime VR be useful?

#20

It would be but, panoramas are more for something rotating around you rather than you rotating around something, i imagine.