Intraobject data security

Howdy!

Eloise touched on an issue I've been pondering for my current project.

That is, how does one harden an object to ensure that data passed between scripts in a single prim remain as secure as possible? The object, an RPG engine, will be distributed to people for their use, but the internal workings need to remain a secure black box so that people aren't tempted to alter their character stats.

My current strategy is as follows. Please point out weaknesses?

1. scripts only linkmessage each other once they've verified:
----a. they're in an object that was created by me
----b. they're at the proper linknumber
----c. no foreign items (e.g., linkmessage sniffers) turn up in the inventory list
2. the data passed back and forth is encryped using xorbase64stringscorrect

if the scripts fail the verification, they delete themselves with a warning to the user.

Of course, I'd very much prefer to cram all the functionality into one script, but the memory limit just won't let that happen.

Thoughts on tightening this up more effectively?

One possilbility is to store teh data remotely in something like a mySQL data base via an SSL encrypted http request to a webserver.

You could easily make the item no modify, so external scripts cannot be placed within, however if you really need it to be modify, you have a couple of options:

1) Organize it such that all of the sensitive data and calculations are in a single script, and simply report the values to the "data displays." A user added script may still interecept and modify the transmissions, but all that would allow him to do is modify how the data is "seen" and not the data itself, as all of calculations are done in the secure script.

2)Move the sensitive data to a server within SL, or outside of it through HTTP, as was already suggested.

3)Have the numbers used in the link message follow a ~30 number sequence, using the next number in the sequence each time. The recieving scripts also cycle the numbers they will recieve following the same sequence, making it very difficult for an external user who doesn't know the system to send valid messages.

4)Anytime change&CHANGE_INVENTORY is true, have it throw a fit

-Kokiri

Hi, Ron!

I had pondered this as a pretty secure option, but was hoping to avoid it as it presents a lot more backend labor. In your experience, how responsive is this? That is, is data transmission lag a significant factor here? I'm reminded of Jakob Nielsen's work on response time usability concerns, though I admit, the main reason I haven't already gone this route is because I'm lazy.

At the very least, I'll be delving into this, perhaps using Zero Linden's Silo approachas a means of offsite data backup.

Good point! I failed to mention that the units used by players will most certainly be no mod.




This one is definitely happening. Awesome idea!

With the SL-based server, I imagine the same issues coming up as with an external server, i.e., using llEmail to communicate would require a LOT of subscripts to handle the email comms. I'll have to ponder that a bit more for an elegant solution.

Other ideas out there?

really depends on the data being downloaded, but lsl only reads text so it shouldn't be that bad just make each line a CSV to reduce the number of lines to read.

ex:
assuming you're using 6 stats and hex codes for gear

stats=15,18,16,14, 15,12
equip=00,05,AF,C4

or if you want to streamline it further make it all one line

15,18,16,14,15,12,00,05,AF,C4

doing this will allow you to put predefined equipement lists in notecards inside the item and minimize the output for more optimized database loading.

If the object is no-mod, and you use very obscure data channels (you have 4 billion to choose from), you shouldn't have to worry about security at all.

I would recommend only using an external server for backing up character stats; it's not worth the possible lag otherwise. A command to backup your stats, possibly automatic, would send them to a server, where it would associate your stats with your key. A new pack could have a restore command, in case your old one is deleted. This could also have the useful side-effect of making it easy to look up someone else's stats.

i agree its overkill if the script is naturally secure in the first place, but one thing ive had luck with in the past is BSin my own encryption

ie chopping up keys and rearanging them in a set pattern, it would take a while for someone to scan for your object, figure out the commands (if your not making them oboius like DIE+NAME) and rearange the data the exact way your script does

maby toss in some 64 bit biult in stuff to make it harder ...

but on a large scale your probally biting yourself in script execution time

its like living in a bomb shelter, shure your safe, but it would get annoying to wait 5 min for that blast door to open

I have a main script, in which I've hardcoded a list of the names of all needed scripts and files. Yeah I know hardcoding is bad in general, but it is secure. I also have to allow various items to be added to the prim by strangers sometimes, so security is kinda difficult.

Anyway... on state_entry, on CHANGED_INVENTORY, on CHANGED_ALLOWED_DROP, and whenever else I feel like it I use llGetInventoryNumber and then step through all contents... any name that's not in the approved list gets a llRemoveInventory.

It's still possible that one of the other scripts could be deleted and replaced with a script of the same name. That can be tested for at run time by sending unimportant data and expecting a specific response back... if the response is wrong you know this has happened. Because of what I've done, nobody can plant an extra script to listen and learn the correct response.

I would recommend: http://secondlife.com/badgeo/wakka.php?wakka=LibraryPseudoRandomGenerator

This makes it very hard for anyone to replicate a message they have intercepted as the channel your script is listening to will be constantly changing. Combine this with some light encryption and the chances of someone getting through it are very small. You could also use this with linkmessages, just sending the random number in the integer argument and having the receiving script check it.