LSL Wiki Mirror 10-5-2006: ScriptSecurity

Script security how to

Overview

Keeping your script secure requires that you both make your script -mod and keep the keys and communication channels secret. There are ways to make open source scripts secure; however, it is much harder.

First, you have to understand that there is no such think is absolute security and the goal is to make so difficult that no one will bother. This means that you should use stronger security measures based on how likely someone will want to break into your system.

The method you use to communicate will determine how secure it is to start with.

There are two parts to secure authentication, and you may only need one. The first part is preventing others from seeing what you are saying, and the second part is being able to trust that a message is coming from whom you think it's coming from. Often in LSL, the latter is really the only thing that matters. If you can ensure that your objects will only listen to each other, does it matter if the information they're sharing can be heard by a third party? You can key the key of a talking object by using llGetOwnerKey(key id) provided that the talking object is in your sim or adjacent? V1.10

Chat

There are 4 billion possible chat channels for short range communications, however it is possible to set up script to scan all possible channels over a perid of time. You can make scanners almost useless by using one encrypted channel that then changes the channel that the data is passed on. This reduces how often the "One time pad key" is used.

Making keys using Math

You can also use "Psuedo-Random Number Generators" to generate new keys, however if someone finds out which equation and starting key you are using they can then predict what key is next.

This is probably the fastest method of encrypting data since you can use the Psuedo-Random Number Generator to create a "one time pad" for use with the llXorBase64StringsCorrect

Some examples
1) LibraryPseudoRandomGenerator
2)

x = (x * 2) & 0x3FFFFFF ; 
if ( ( ( x & (1<<19) ) == 0 ) ^ ( ( x & (1<<27) ) ) == 0 )  ++X;  //Create one Pseudo-random bit in LSB

Not tested needs it's own section

(AlexanderDaguerre) I don't know where the above generator came from, but I'm guessing that it was copied from some other source. However, if so there are at least two typos in the above code. One of them (caps vs. lower case X) makes it not compile, but that's not very important. The second typo is more serious, as it makes the generator repeat every 19 steps once it settles down. As written, the masking with 0x3FFFFFF means that bit 27 will always be 0 after the mask, which reduces this to a single-tap generator. You can verify this by running the following script and noting what it says about the value b and the intermediate values:

default
{
    state_entry()
    {
        integer x = 0x12345678;
        integer i;
        for (i=0; i<100; i++) {
            x = (x * 2) & 0x3FFFFFF ;
            integer b = x & (1<<27);
            llSay(0, "Intermediate state " + (string)x + ", bit 27 is " + (string)b);
            if ( ( ( x & (1<<19) ) == 0 ) ^ ( ( x & (1<<27) ) ) == 0 )  ++x;
        }
    }
}

Finally, you should be aware that this whole class of generator is known to be insecure for cryptographic applications. The outputs of the generator leak too much about its internal state: if you have seen 2n bits from such a system, you can determine both its current state and the tap sequence. You really should not use this generator (even without the typos) to produce key material.

Signing Messages

from Lex Neva
You can also sign messages using llMD5String. This computes a (theoretically) one-way hash on the input, which can be used to "sign" a message. With every message you send, run llMD5String() on the message with the password stuck at the end. The other end will also run llMD5String() on the message it receives with the password it knows about stuck on the end, and if it gets a result that matches yours, it knows that you had the password when you sent the message.

The only problem is that any eavesdropper can get a message that you send, plus the MD5 "signature", and just send that same message again. This can be a security vulnerability in some cases. To mitigate that, you should instead MD5 a string like this: "<my object key>|<password>|<message>". The other end will do the same to check the authenticity of the message. Since (as far as I know), it's impossible in SL to spoof the source of a message that's received in a listen() event, this is much more secure.

Creating truly random numbers

The llFrand function will return random numbers; however, the numbers it returns will only be truly random if some other random numbers are generated in between in a random fashon. So grab a random number and then another and discard some based on some other event like a timer if you absolutely have to have a truly random number.

Functions

Function	Useage
`llXorBase64StringsCorrect`	Allows you to use "one time pads" to encrypt data.
`llXorBase64Strings`	More info on above.
`llFrand`	Used to create random numbers.
`llModPow`	Very weak and too slow for most uses.
`llMD5String`	Used for signing messages

Contributors

grumble Loudon, LaserFur Leonov, Lex Neva, Thraxis Epsilon, Hank Ramos, Hewee Zetkin, AlexanderDaguerre

Threads

http://forums.secondlife.com/showthread.php?t=126143