Encryption of viewable data in SL, and the issues with it.

All right. After looking at several encryption systems in SL, I have come to some basic conclusions:

1- 64bit encryption takes about 30 seconds to process on a medium length string in SL. That's no a sim with no lag. Numbers go up from there, and are doubled when you consider decrypt time takes just as long. See /15/c2/13580/1.html

2- The lighter encryption listed in the Wiki at http://secondlife.com/badgeo/wakka.php?wakka=llXorBase64Strings is extremly vulnerable.

3- That the psudo-random changing of chat channels is not enough, and that allowing data to be intercepted in any way is a bad thing on average. See http://secondlife.com/badgeo/wakka.php?wakka=LibraryPseudoRandomGenerator


What I propose is this then: Multiple layers of security.

- First, encrypt data that is not important with version 2 security, using a key file that is chosen randomly from a list. The number of this listed key is added as a header to the data stream.

- If the data truly needs to be secured, then it uses the encryption method 1 above and deals with the delay by assigning the process to a sub script to watch for it.

- Last, the data stream is then broken into multiple parts and sent over multiple llShout/Listens that are each using seperate security keys to randomize the channel (security version 3 above). The chances of someone getting all of a data stream is reduced to a minute random chance, and even then, they will never be able to get more than snippets of data at best.


So, all data is not only encrypted, but scattered to the wind and reassembled at the destination. The worst vulnerability is that there must be a list with all of the data in it contained in the sender and receiver units, and that if this 'keycard' gets out all bets are off.

All of the communication system would have to be updated manually, since any automatic system to update security would be moot once the network was breached.

Would anyone else like to discuss this concept?

So both sides of the communication has a list of keys, and the encryption decides which key to use and lets the decrypter know by added the int of the selected key to the header?

Frequency/Channel hoping is good. It is generally used to prevent radio interference but it provides some marginal level of security. I could imagine a malicious data harvester owning a SIM and allocating resources to try to listen on as many channels as possible.

The only other problem I see, is that since your keylist is finite, the same key will be used to broadcast data multiple times. The more times one key is used the easier it is to start to identify common content and thus eventually crack the key. Also if the cracker was able to create the data stream to be encrypted/decrypted (like say encrypted Nexcom devices), then it becomes even easier to crack keys that are used multiple times.

That being said, those aren't easy attacks to pull off. Your scheme is a good general encryption policy. As long as you aren't trying to hide anything from the Feds you should be good

But if you gonna have matching keylists in each object, might I suggest a One time pad.

One time pads are a pain to code in some respects. You can fake one with a moderately large encryption pad and a modifier, say the date of the message. It is still crackable, but it's harder to do, you need a much bigger data set to do it.

But does this look like it will reduce the chance of an average person cracking the encryption to near-null? That's the question. It's not the Lindens I have to watch for. It's forgone they can see it. It's the idea of someone using a sim to try what you advised.

Lets see. 10 million channels.

a script can listen on 64 channels, so they would have to have over 150,000 active scripts to watch them all. even %10 coverage to watch for it would be 15,000. And %1 would be 1,500 scripts... Seems a sim would die under that kind of load. Either that or fail to keep up with anything like the dataload we're talking about.

Or am I underestimating the number of scripts that can run?


Regardless, they would have to catch all 2-4 channels of data to get an unencryptable string, and since the channels change independantly...


Finally, they have to decrypt it, and since there would be perhaps 99 keys randomly used....

Wait! Even better! Use the psudo-random number generator base on 30 minute shifts and have it added to the encryption string too! This would mutate the data even more.

But, what stops them from taking that full string they lucked into and just attempting to decode it until they figure out the code with brute force?

How will they know they got the right message? Even if they do crack it, they have no proof without another code that's exactly the same to prove it against.

This may not be unhackable, but I can't think of a way through it.

Then again, I'm not a cryptography expert.

Your right, it's not a practical attack.



This all depends on the implementation. If they could magically capture all the data on your channel hopping over the course of 3 months and you used the same 99 keys for 3 months, then it's possible to decrypte the keys. Especially if your sending lots of messeges with similar content.

But I agree, it looks like pretty darn good security in SL. Cryptography is a tricky thing, anyone else care to weigh in?

Well, I am not a cryptographic expert (IANACE?) but I do have some experience here:

First, let me laud you on discussing the scheme publicly. Nothing fails so hard in crypto as 'security though obscurity'. The proven way to make secure systems is to make the protocols public.

It is hard to evaluate your scheme without knowing the usage scenario. As Satchmo points out, if you use the same 99 keys over a long enough time, even with channel hopping, the determined attacker could feasibly crack your keys.

Looking at the pseudo-random sources cited, they are all not very good. In RL, it has been shown that poor pseudo-random sources can be much more easily exploited than one might casually think.

One-time pads are generally a pipe-dream: They are very expensive to generate, and you must have as much key material as information you are sending. So, except for occasional short messages ("Attack at midnight" they aren't generally practical. (In RL, one-time pads are generated through manual, physical processes like rolling dice. I've toyed with the idea of using the physics engine of SL to do the same!)

Real encryption is SL is just too slow. For what it's worth, I have a working RSA implementation in LSL. Alas, it takes 7 minutes to encrypt a 32 character string with a measly 64-bit key. Maybe when we have the Mono virtual machine....

I have looked into implementing AES, and it might just fit. However, most efficient versions of AES (or DES for that matter) rely on large static look-up tables. There is no way we can store that much data in a task. (Yes, we could distribute the tables over multiple scripts, but that turns table look up into communication, and negates the speed advantage.) I will probably work on this in the near future...

If one could pull off real encryption in LSL (such as AES), then all the channel hopping stuff can be dispensed with, and that would be good: It only offers a minimal barrier.

I do have a great interest in cryptography in SL: I'm opening a Notary in SL, and it is heavily dependent on cryptography. The algorithms are all standards (RSA, MD5, etc.) and the protocols will be all published.

Ah, you missed a part of it: It's not JUST channel hopping, it's also channel SPLITTING. parts of the excrypted data being sent over multiple channels at once.

The point is, they have to get ahold of a full communication burst, using the same key of 99 keys, and that key is also altered by a psudo-random number generated every hour (or less) or so...

Then they have to get ahold of another to compair against. What are the odds? Would brute force hacking of this even be possible?

So you have 99 keys, chosen at random, altered by a psudo-random number from the time, and chopped into parts and scattered across 2 or more channels.

What more can you do in SL to make it secure against hacking?

I don't think splitting makes much difference...

The underlying encryption mechanism you are using is XOR. You can find the cryptographic properties of this algorithm in a text such as "Applied Cryptography" by Bruce Schneier: They are pretty bad. It is easy to crack, easy to deduce the key, and this can be done with rather incomplete sections of the crypt-text. It is also very vulnerable to man-in-the-middle attacks.

The method has been complicated by a number of things: multiple keys, splitting up the encrypted text, key modification by a function of the time. To my eye, these complications only put up small barriers to decryption compared to using an underlying encryption method that is stronger.

Now, I don't know the details of your modifications, and even if I did, a full crypto-analysis of them would take quite some time. Given the computationally starved environment of LSL, I think it is natural to assume that some simple things can make hacking unfeasible as your attacker can't put that much compute power on it (like listening to all channels). However, my back of the envelope doesn't put it too far out of the realm of possibility. For very secure communications, you want cracking to be several orders of magnitude harder than you think your attacker has access to.

Lastly, remember that the weak link of a crypto-system is often some other aspect like key-distribution, or social-engineering.

If what you're doing involves securing turn instructions to a game server, then your method may well be good enough. On the other hand, if you are shuttling tens-of-thousands of L$ about, perhaps you'd like to IM me about my AES implementation work...

If it were me, I'd use a triple barrier of security here.

I'd start with a very simple algorithm that Strife and I provide here. This allows you to fetch multiple, predictable channels (or pins) using the key of an object.

Then, I would use this obtained value to llRemoteLoadScriptPin the "payload" script into the object that then opens a listener and/or signals for data processing as a link in the chain. Alternately, this could be done with email... but a security system is only as strong as its weakest link.

This "payload" would function only within a select timeframe, adding to its security somewhat. The real benefit of managing it with a remote script is the fact the person requires "modify" permissions, making for a VERY secure system. Once the listener is open, I would auth against the key and current time value and send the encapsulated message.

------------

But yes. Encryption and data protection is woefully incomplete in LSL. What we really need is a message-based perm mask function from the Lindens, but I bet that's low on the totem pole.

Heck, Post it here for everyone to look into. That's what it's all about!

How long does it take to encrypt though? This has to be real-time communication in most cases. 30 seconds to encrypt would be a problem due to the possible volume of data being communicated.

Problem is, what your proposing sound like it was built more for direct communication between systems than the open broadcast network relay I was talking about.

The data is actually being relayed between repeater nodes, and devices on this network 'listen' for broadcasts that are directed toward it's own key (or some other id system). The targeted system then decodes the data and processes it in whatever way is needed.

That's the fun part. All you have to do to broadcast a message is run a sensor through your towers by name and even direction. Multithreading through the llRemoteLoadScriptPin delay is another factor, but easily gotten around.

The only potential downside is the fact this is limited by 16 returns/event, but I'll assume we're not dealing with that many here at once?

To give you an idea of where this comes from, it's actually the concept that runs the channels for Primmies, our Game Dev entry. While it doesn't obfuscate the code that much (since hacking it wouldn't exactly gain much), I do know that using this sort of sensor/channel combo is extremely fast and light-weight, with the added advantage of being able to use llGetOwnerKey for the returns.

Anyway, I just figured it might help, since it's a concept I more or less had to pioneer for handling game processes flying in 20 different directions simultaneously, and works extremely well.



Edit: So the detailed workflow looks like this:

- Querying object runs a sensor for obfuscated objects with name "DataTowerv5"

- Sensor return gives keys for towers in range, which are then used to decode remote pin access code and other fields for llRemoteLoadScriptPin

- Querying object sends payload script to tower(s), which in turn link message data received via listener

- Querying object then sends along data encrypted and cross-checked by method of choice

- Querying object sends close command, or timer expires in payload script. Script removed.

- If necessary, towers continue this chain of sending similarly-named scripts to other towers, using their own sensor events. Process continues until data reaches secure server.



The added benefit here is the fact there is a time factor that is difficult to determine, a mechanism that requires Modify rights to trigger by a client, and additional encryption/verification in your method of choice. If you're really crazy about security, you could even focus the sensor into a "beam" and point it directly at certain towers, further obfuscating transmissions and attempts to thwart the system.

It's not a perfect system, but I'm personally a fan of this sort of workflow.

Confucius say, man who wants to use game for serious business, smokes mucho opium.

To stray off topic:

A link to the Serious Games Initiative

The upcoming Serious Games Summit

also an upcoming Games for Health Conference




Back on topic:

I agree with Zarf. The only way to really secure data is to use standard Cryptographic algorithms (AES, 3DES, RSA, etc). It depends what you are trying to do that determines if you need this kind of professional encryption. If it's something serious with real legal and financial implications, like a notary, than it's something you definately want.

There are lots of projects in SL that would only require best try encryption.

My intention of creating Pseudo-Random Generator function was to use it for fast channel hoping (10 -> 60 seconds) where any and all the variables could by made dynamic.

The goal is to put this in the hands of a user you don't trust and not have to worry about them hacking it.

About MD5:
When using anything with MD5 you should pad the string. Why? because if the user knows the string that was fed to MD5 they can crack the nonce in under a day on a single computer. Adding extra characters as an extra nonce means they have to try every character combination along with every number nonce. Brute forcing is easy to do if it's just the nonce that is modulated.

About Base64:
If you are going to use Base64 be sure to morph your XOR and add in junk into your final string. If you don't morph the XOR it will be easy to reverse calculate (because the conversion with llBase64ToString only works on printable characters). Adding in junk means they have to figure out your junk algorithm too.

Putting it all together:
Method of communication: Pseudo-random channel hopping based off MD5 checksum of a string that is changing regularly, with some nonce, all time based.
Chat: Base64 XOR with a pseudo-random value; then pollute the the output with dynamic junk characters. This will help hide your XOR (and data in turn).

If you're psychotic you can then split it up into lots of little packets and send them over multiple channels all at the same time. Personally not my favorite as it adds an new layer of failure (lost packets and coping with lost packets). Oh and if you want to screw up your hacker, send fake packets of random data on random unused channels.


If your goal isn't to secure data but keep hackers from influencing your data, just using pseudo-random channel hopping is probably good enough. In a combat system you don't want players hacking the system but the data really doesn't need to be encrypted (and encryption is slow). Tamper-proofing is easier and faster then securing.

How about oscillating the encryption method against data "envelopes". Each envelope contains a private key scheme for it's own data packets. For example, you transmit packet 1, encrypted with method X. In a random location within packet 1 is the key for packet 2. Packet 2 is also encrypted with method X, and holds the key for packet 3, etc.. The packets are sent in random order within an envelope. Each envelope contains a random number of packets. The entire message consists of any number of envelopes, possibly all sent in random order, but each envelope is encrypted with a different random method (some overlap is ok as there are only a handful of viable methods known).

Within each envelope is a public key packet that allows you reorder the data packets in it appropriately. And then finally there is a public key envelope allowing you to match the envelopes up, as well as their individual encryption methods. Throw in a final measure, a checksum scheme for the keys.

This is all theoretical, but I think it's something being used already (read about it somewhere or other). In practice I imagine it would be heavy, but probably enough security to handle $ transfers.

You can take the depth even further in SL by oscillating the transmission channels.. perhaps each envelope also contains an encrypted representation of the channel of the next envelope...

If it's financial information then I too agree with Zarf. Use a standard Cryptographic algorithm, they have been tested. RSA is processor intensive so that leaves you with AES or 3DES. AES is a good choice.

Really, the question is more about risk management and good cryptographic practice. You can get a lot of good information on that subject from Bruce Schneier's News Letter and web site. Hope this helps some. -- Rose

http://www.schneier.com/crypto-gram-0508.html

Nexcom 3 uses base64 xor with an md5 password and the md5 salt changes each minute
Nexcom 4 uses a custom system thats not disclosed that breaks the string down into a list and then works with chr() and ord() style functions.