Licence Files

Any thoughts on how I can make a licence (aka license for our American cousins :} ) file?

I have a whatchamahoosit.

My idea is you would drop in one licence file that says it's good for 3 people at once; then 3 people can use it. Or, you drop it another licence file that says it's good for 5 people.

The licence file (a script let's say) would be dropped into the same prim as the engine script, which would say is there a licence file and if so for how many. The licence file would answer back, yep, I'm here, I'm good for x persons.

The two would communicate via linked messages.

Here's what I already know.

(A) Really strong RL encryption of the linked messages doesn't exist in RL;
(B) Many of the strongest schemes in SL are really quite slow, and probably overkill for this need ( and some have so much code that I looked at them and went holy crap, there'd be no memory left in my 16k to do anything else...);
(C) I can authenticate by checking that the licence script was created by an authorized person.


I've been combing this forum for about 6 hours now; have a bunch of loose ideas in my head, and thought it was time for some outside thought.

I think I want to pass a reasonably secure message from the licence file to the engine, that the engine can translate into knowing what number of people it is authorized for. By reasonably secure, I am not trying to keep out the KGB or the American Homeland Security :}

You'd probably be just as well off making versions of the script for various numbers of 'licensed' users.

Advantages:
1) No messages to intercept.
2) No need to create/read "secure" communications.
3) There'll be one less script to add to lag.

HTH
/esc

nah, thanks but looking for a broader solution that can be sold from a dispenser. I'm pretty fanatical about keeping the number of scripts I use down to a minimum, so I think I can allow myself this one luxury :}

If i was going to do something like this, I would likely have the item poll a website out of world for the licensing information, using RPC or HTTP(S). You could create a much more secure license scheme this way, as interception of the information is hard if not impossible. even llEmail out of world would be miles better than linked messages.

i`d go for the http request

created a serial system with the use of the xtea encryption, but must add a warning
if your going that route and add a couple of functions and alot of code, it will be wise to start from scratch using 2 scripts with linked messages as polling the page several times consumes memory like mad wich throws out stack-heap errors

mainscript - do all the normal stuff
http - to do all the queries, http result checks and then pass a couple of vars back to the main script for normal proccessing and reset the http script

just ran into that problem myself but only with ~1100 lines of code to cutup into several scripts, so if you have a hunch it will consume alot of memory, play save and do it right from the start

Thought of that, but as an old-school IT person I want something that won't stop working if I get hit by a car, etc.

on sale: send to web "just bought"
web records key of buyer and date
on rez/attach/use, item polls web for permission to work
web decides on your cretieria, whether to say yes or no.

if you get hit by a bus, that service continues working, so long as the site hosting the system continues the hosting.

This is a system that can be used for expiration dates.

similarly, you add a button to the script, the owner touches it, and gives permission by "stating the name or key" of each user they wish to authorize. If this is something more centralized, you could build a system that allows members of a certain group (inworld) to command the system core. by clicking a button inworld, they could authorize people. (if samegroup, accept command).

the main issue with systems like this, is the leap from SL to the "real world".. these systems aren't 100% reliable since LL rarely pickes up their tools when they work on things, and sometimes things like XML/RPC or Email get broken unexpectedly.

It really depends on WHAT you're trying to accomplish, as to how best to approach it's solution. I made a "product killswitch" out of an update server. (if update is available (success) llDie)

Well, depends on what your threshold is for how far someone needs to go to break your encryption, and how much you care. Unless significant amounts of money were involved (or other peoples' money was involved, i.e. someone could come to me and say "Hey I lost money because your script was buggy", I'd probably settle for something not too elaborate. So probably something like:

* Keep a shared magic 'key' that both scripts know.

* On request, the license script generates a message that contains some verifiable pieces of information, and the number of licensed users. Say, object key, today's date, current sim name, whatever.

* Encrypt this information with the key, send it over. Decrypt on the other side, see if the generated pieces of information are correct, and if they are, then decide you can trust the license count information.

Note that I've never done cryptography-related software development, so this is probably full of huge holes

I'm going to give a bit of direction here rather than a straight answer. You don't need full encryption. There are no secrets being communicated between the scripts in the scenario you describe. All you actually need is authentication. That is, all you need is to be able to verify that a message came from an authorized script.

A common way to do that is with a signature added to a plaintext message. The signature is computed using a secret key and a one way hashing function such as llMD5String() (which isn't wonderful in terms of security, but it's decent and more than adequate for most LSL systems). The tricky bit is that you need to figure out how to add enough information to the plaintext message to prevent a signature from just being reused. That often means doing something like including a timestamp, or using a challenge/response scheme where the script being authenticated has to answer to one or more facts chosen by the script doing the authentication (the latter might be more trouble than it is worth though, since you usually have to preserve state between challenge and response).

What information you need to include to make your system secure usually depends a great deal on the particular application. Whatever it is, it has to be independently verifyable by the script trying to authenticate the message(s). Using a timestamp for this can be good so you can make it tricky to reuse messages by creating a very short window during which the signature could be reused. It can be a little tricky though. The script verifying has to check that the timestamp is within a certain interval around the current actual time, and you have to decide what to do if the authentication fails, keeping in mind that there might be script delay and/or sim lag that interferes with a correct interaction. Other/additional choices that might make it difficult for a signature to simply be reused where you don't want it to are object key, prim key, owner key, or even some aspect of the prim/object location. You might also pay attention to the prim the link message is coming from, and only accept ones from the same prim, or the root prim, or whatever is appropriate.

Hope that helps.

while it's a hair less favorable then a notecard solution a script variable would satisfy your needs without being overly hard to maintain. as would hiding a pim property "counter" in a no-mod object (or heck just tacking the usage number on the end of the script and reading that in a no mod object)...

assuming it's mod, a note card is readable by any script in the prim, so isn't very secure. you may be stuck with e-mail/http/rpc... that said it should only need to check on startup or owner change, at which point it can store the information locally, thus reducing your chances of (being hit by a car) at the wrong time..