Communication Encryption

Hi guys

Is it possible to two-way encrypt and decrypt data and using a key?

Basically I want to be able to send data between two or more objects that are in the same region but I don't want anyone to be able to use this information. It's not anything that would be a disaster if it were decrypted but I'd rather not keep it unencrypted if I can avoid it.

I've considered using email instead but I need an instant response as soon as the sending object has 'said' what it needs to so waiting while the object scans for new emails would be too slow. The receiver should respond immediately so that the original object can then do whatever it needs to. I know there is a server overhead in any encryption but I'm not talking about massive amounts of data.

Since I need to be able to decrypt the message and it can be of almost any value I obviously can't use one-way encryption techniques such as MD5 to check what has been sent.

Any and all help gratefully received as always!

Cheers

Landing

It sounds like you aren't very worried about someone trying to break your code, and you don't need very secure encryption. If that's the case, this is a very simple method, but one that could be pretty easily broken if someone really put their mind to it.

NOTE: The forum is inserting extra whitespace. You should be able to get around this by quoting this post and copying out of the edit box instead of the formatted result.

// Just some randomly typed private key (without quote or backslash characters)
string PRIVATE_KEY = "_#WQ(N*X23409c5)Q4)(V0349wwq0394c_)m$-3V280";
string PRIVATE_KEY_BASE64 = "";

string encrypt(string plaintext)
{
    if (PRIVATE_KEY_BASE64 == "")
    {
        PRIVATE_KEY_BASE64 = llStringToBase64(PRIVATE_KEY);
    }

    return llXorBase64StringsCorrect(llStringToBase64(plaintext), PRIVATE_KEY_BASE64);
}

string decrypt(string cyphertext)
{
    if (PRIVATE_KEY_BASE64 == "")
    {
        PRIVATE_KEY_BASE64 = llStringToBase64(PRIVATE_KEY);
    }

    return llBase64ToString(llXorBase64StringsCorrect(cyphertext, PRIVATE_KEY_BASE64));
}

See http://www.lslwiki.net/lslwiki/wakka.php?wakka=llXorBase64StringsCorrect

I don't know how fast you really need this to be. I regularly use email for interobject communication. A fast polling cycle is needed, like every second. That can tax sim resources, but it accomplishes the job.

I'd suggest that you do a search with key word encryption on this forum and you'll find lots of discussion about the topic. The short answer is that very secure encryption is just too slow to be useful in SL. There are less secure approaches that will deter the casual user. Just how secure do you need this to be?

It's mainly because commands for various systems will need to be broadcast, and done so quickly. Working on timers I need things to happen quickly, but I don't want a listening device to know how things work. If they do then anyone could create an object that can interfere with the operation of the device.

I'm already looking at different workarounds, like using a synchronising system that means that the receivers will only listen to the registered transmitters, amongst other things, but that doesn't stop people synchronising with third party applications that are piggy backing onto my technology. I've already made the mistake once of discussing how I planned on working something and another user went and used my ideas to win some cash award for innovations. I'm sure you can imagine how annoyed I was at that. I just want to be able to protect the command structure that is used in a multi-object system where possible.

Email polling every second just isn't a very tidy solution for me, though it is what I use at the moment. I'd much rather be able to send information through normal chat channels.

Just how secure would you describe your method Hewee?

The method described by Zeewee is about as good as it gets in SL without having to resort to fancier but much slower methods. If you kept changing the key every so often, it would probably be good enough for what you're trying to do. You could for example, send out a new key every hour via email.

Hmm, that's an interesting solution. I figure the best way to work this is that the owner 'pairs' the devices together where they pick up each others UUID, then the key could be sent by email in that case. (I was originally going to have a key for the range, rather than one per pairing)

Is it possible to have multiple timer events then? I only ask as there will already be timer events with random lengths running so I figure the only way to time it to an hour would be to keep adding the times together until an hour is reached and then reset it to zero again?

This project is requiring so much planning already! I'm glad I am planning it rather than just getting on and seeing what happens, but I feel like I've been at the planning stage for far too long already

Just put together a little demo for my own benefit to try the encoding and decoding to make sure I understand properly and it seems to be working great, thanks. I'll look at sending a new key next and make sure that works.

As a thought; reading up on this method on the Wiki it states that this is only really secure when the key is only used once. With this in mind, is it worth sending a new key on the end of every command? I know the key would be encrypted when sent so would be decrypted to the next key to use and I figure that way the central 'hub' could store a list of paired devices UUIDs against the key used for that item, updating the key every time.

Any thoughts on that?

OK, I think I'm starting to understand this now and its limitations.

I've just set up the system to send firstly the UUID of the agent who clicked the first object, followed by a simple message "Touched."

When reset, the object sends the owners UUID and then the word "Ready."

The message is then relayed to the agent whose UUID is sent via llInstantMessage.

The Ready string reads as follows:
OUVmZR8vGWAfCgYFW04BGWUHBBE1UgAZCkNDFFIBWFYGZxpbCH9WN1ZB

The Touched string reads as follows:
OUVmZR8vGWAfCgYFW04BGWUHBBE1UgAZCkNDFFIBWFYGZxpbCHlcI1FQVTsN

You can see clearly which bits are the same and which bits are different, especially when immediately on top of one another:

OUVmZR8vGWAfCgYFW04BGWUHBBE1UgAZCkNDFFIBWFYGZxpbCH9WN1ZB
OUVmZR8vGWAfCgYFW04BGWUHBBE1UgAZCkNDFFIBWFYGZxpbCHlcI1FQVTsN

OK, so that leaves a pattern which is clearly going to be a problem, so I've had the transmitter stick a new randomly generated string [md5(randomnumber)] on the end and send that also, so the string goes as follows:

AGENT_UUID,MESSAGE,NEXT_KEY

Repeatedly clicking the object sends the following messages (remember that decrypted they're all the same):

U1FTUg9RCl5IWAMNUR4BAwNVTlhQBFIZV1YBUVVQVABQD1FQFGRWEwYJVFwfBwBRVQJSVAsHUw0BVQ0HAgZWAVYEVQVZAQkHBFQACAs=
UlNTVlNQBgBMCwtQVRUHBVBQTlpQVVBMAgRVBFcDUVpRDVFUSGVaTQJaXAEbAFJXVwUHUwBVVVgABgNQVgIGC1UEWwYHBFAIBAoOAAY=
XgdTB1EFAwtPDwsEVE8FUwcFHlhSW1dOBlEEAFoFBFNdWVEFSjBfRgFeXFUaVARQAgICUgYJUloNVQgHCwUDBV4AUQRSXFMFAAMKAwA=
UFMCBQNQAA8dDwsNUhVWAwZVGV8CUQQZC1cCB1cBU1RTDQAHGGVcQlNeXFwcCFdWAlBSUQRVBwIOUQ5QBVcKBVMCUVMDCAUCVFQPC1Q=
VlNUBAEHBF1LCQQDUBUGAFALHlxUAFEaCgIBAQAEUgZVDVYGGjJYEAVYU1IeDlMEAQ0KA1FbBgZaUFYBVgYCXQBXAwVVUlIGBAJTBVM=

Although the messages now appear to be encrypted to a satisfactory level, I'm noticing that loads of messages now have an equals sign (=) on the end. I wonder why that is?

Also, I'm aware of the fact that the trasmitter needs to receive a message in return confirming that the new key has been accepted and which key it was else there could be confusion as to which key is being used in which message if they are received out of order.

This is requiring more brainpower than I'd bargained on!

The = signs just are padding characters in base-64. They indicate that there are no more data bits to read for that string, since every 4 characters are 3 bytes. If you only needed two bytes, it still would need to output all 4 characters.

Xor encryption is trivial to break, even with significant levels of obscurity.

However, right now, it is all that is available if you need speed.

OK, the chances are that nobody will even find the broadcast, never mind know what to do with it, but any extra protection I can put in the better for now. I'll keep up with the regenerating keys for now, they work nicely so even if someone works out the key used last time they won't know what the next one is so they can't get onto the 'network' (I hope). The actual information sent isn't a problem if it falls into the wrong hands but I don't want people injecting information that they shouldn't be into the system. Listening only to certain UUIDs should help too.

Thanks for all your help guys

You may want to also/instead add an MD5 signature of the message with another private key (this one can be fixed without too much worry) appended then. That way the receiver can verify the authenticity of the message. Authentication is generally a lot easier then encryption, and this is a lot stronger than the encryption mentioned here; an MD5 hash is very difficult to attack (especially if the attacker can't inject known plaintext messages for encryption).

Also, in case it isn't obvious, I suggest choosing a randomly selected large-manitude channel number for the communication. Maybe even with channel hopping. That's actually one of the easiest forms of "encryption" available in SL, and is usually sufficient for most applications.

sounds more like you need authentication than encryption.

Void, it's a bit of both. Yes I need to authenticate to make sure that the right objects are sending the commands, but at the same time I don't want the command structure to be released where possible.

Hewee, let me check I'm understanding you correct and give a little insight into how the system is supposed to work...

1) First device (lets call it the hub) listens on the 'sync' channel
2) Second device sends a message to the hub telling it what kind of device it is. The UUID is grabbed from this message and stored by the hub
3) The hub emails the second device with operational settings, such as the channel that it operates on (randomly generated) and what key it will be using the next time it sends a command to the second device
4) The second device emails back its operating channel and the key that it will use when it sends a command to the hub next. If the channel is the same as any other on the hub then the hub sends a further email back advising to generate a new channel, else sends an email confirming synchronisation and ends the process.

All further communication is performed over the randomly generated channels, with each sending the next 'encryption' key within each message. Each device connected to the hub will have its own pair of keys for both encryption and decryption.

Now, I assume that this is where you would use the MD5 to verify the source? I assume that if the hub is listening to a particular UUID that it's not necessary, or is it? And if so, should this be sent over chat as a second message? I appreciate that listening to specific UUIDs and channels limits how many objects can be linked to the hub too. I'm considering ways around this that don't involve multiple scripts (like maybe storing this information externally and verifying it at each point via a web service)

I feel that at this point that the inter-object communication is as secure as it needs to be, I'm just unsure that I've checked that the device being synchronised to the hub is an authentic product. I'm considering a list of authorised items to be held in a database on the web and have this site queried to make sure, probably building in some kind of key for every item and storing that (by every item I mean every version, as opposed to every object). It does, after all, only have to be done once while the two devices are synchronised. I am right that the HTTP requests are between my web server and the SL servers right? Rather than between the web server and my SL client?

I'm not sure that I'm particularly clear in that message, hope so!

Hmm. I'm not sure I can wrap my head around your complete system architecture at this point, but I suppose if you authenticated an object as a valid sender, you wouldn't then have to authenticate each message, since SL has a built-in mechanism for determining the sender of a message (in fact, I'd be more concerned about spoofed e-mails than spoofed chats, since it is easy to spoof the sender of an e-mail). That is, as long as you know no one can add their own scripts to the objects.

Of course, you have to think about what information is used for the authentication. Is it enough that you own the object? If not, are you using messages that can't simply be duplicated (e.g. using some kind of timestamped or challenge/response system, or including some kind of unique and verifyable information in a signed message, such as the sending object's key)?

HTTP requests from LSL code never touch your viewer in any fashion. They originate from the simulator, pass through who-knows-what LL gateways and proxies on the way out, and travel across the Internet to the specified destination. You can get a list of IP address ranges from which these messages appear to originate (I don't know if these are the actual simulator addresses or NATed gateway addresses) from the Knowledge Base.

There are better articles on encryption and authentication out there on the Net than you are likely to find here. We can give you advice on how it pertains to SL and LSL specifically, but I'd look to other sources for your general problem.

I think to be honest that you've all been more than helpful already. I know what you mean about the architecture though. It's quite a lot more complicated than stuff I've done in the past and creates a 'network' of devices that can talk to each other. I think using the UUID will be enough to authenticate the command and I'm happy with the 'encryption' as it stands; it's good enough for the purpose for which we're operating.

I still have a lot of planning to do before I can start the actual code and I hear what you're saying about spoofing emails etc and I think in this case I may look at either returning to chat commands or maybe do it via the web. I'm weary of adding too many different systems which could go down (and therefore introduce a further failure point) but since the pairing is only required once per device then I think the web option may be my best option under the circumstances. It would also allow me to ensure that nobody is using the system who isn't allowed to I guess and remove them from the pairing system.

Thanks again for your help, you've given me a lot to think about

keys, being hexadeximal strings, dont have much space to encrypt, so the only advantage is a bluff of data being something else.

I'm surprised no one has mentioned the XTEA implementation as described in the wiki (they might have, but I was skimming). I'm no encryption expert, but what I read through sounds like its as good as you can get given the constraints of LSL.

http://wiki.secondlife.com/wiki/XTEA_Strong_Encryption_Implementation

One thing not included with the implementation is a method for generating keys. Here's something i'm currently playing with to create keys based on the owner's UUID. (this is rough code, I couldn't remember the correct function name for doing the substring). I also recommend plugging in some random digits for the string sDec.

list Key2Mask(key id)
{
    string c;
    integer i;
    integer x;
    string sHex="0123456789ABCDEF";
    string sDec="0123456789012345";
    string s = (string)id;
    integer l = llGetStringLength(s);
    string t;
    for (i=0; i<l; i++) {
        c = llGetSubString(s,i,i);
        if (c != "-") {
            x=llSubStringIndex(sHex,c);
            t += llGetSubString(sDec,x,x);
        }
    }
    list lOwnerKeys=[
        (integer)llGetSubString(t, 0, 7),
        (integer)llGetSubString(t, 8,15),
        (integer)llGetSubString(t,16,23),
        (integer)llGetSubString(t,24,31)
    ];
    return lOwnerKeys;
}