XML-RPC - Channel 'protection'

The current method for setting up an RPC channel appears to be some combination of opening the channel in game, obtaining the channel key and then using that key to connect to the SL RPC service from your 'server' (With optionally the key being e-mailed to the server)

Each RPC request/response is a plain XML 'file' with the Channel key in it ... in what looks like open text?

How do you 'protect' your Channel from inteference? By that I mean anyone who knows the channel key can interact with the RPC Client. Or am I being too paranoid

Thanks
Leon

bump

My question is similar, but takes a slightly different slant - just how secure is the key of an RPC channel for SL? I can do the maths - 36 characters, 4 bits per character = 144bits to "guess" unless it's more constrained than that?

If you're giving out things like a vendor box is there any way that they can find the XMLRPC channel your script has assigned it? That can be asked as, if I was doing something with your money through an RPC channel in SL, would you expect that the contents were encrypted as a necessary rather than OTT security layer so people can't rip you off?

I'm actually thinking more of an updater server driven this way at the moment, but although I can get the XMLRPC to work just fine, I don't know enough about the security end to work out if I really need the extra encryption too.

If it makes a difference assume, because it's true for me, that everything important "in the box" is currently in one script with no linked messages, so you're talking intercepting the RPC message directly somehow, if possible. Is it?

I think it's 128 bits actually - looks like a GUID to me.


I haven't tested this to be certain, but most external events are per-prim and not per-script so in theory someone could add a script that waits for the channel open event and relay the channel key wherever they want. It's probably best to assume that your communications are open for anyone to see and not trust vendor (SL) security.


Encryption is one of many possibilities for securing transactions. Challenge/response could be another good way. Then there is the matter of script security in a modifiable object, which is probably a bigger threat.


IP traffic can be sniffed at any stage of its travel, which is the reason for encrypted network communications in the first place. If that is your concern, then encryption is probably an option you should pursue.

However, considering that it may be possible for someone to get your channel, we come right back to the issue of script security. How do you make your script know which incoming messages to trust?

Hopefully this sheds some light and gets your thoughts moving in the right direction...

Thanks Apotheus, it gives me some ideas to play with as well as some pointers the right way.

Apotheus,

I'm not sure I understand this statement. What do you mean by add a script?



This makes good sense in anycase. What I'm struggling with is that there is no 'secure' encryption available to SL? llModPow or llMD5... (can't remember the function right now) isn't exactly suitable. Anyone developed proper encryption and willing to share?

Thanks
Leon

Under the assumption that the object containing the XML-RPC script is modifiable (Eloise mentioned that it is a vendor object), the object owner would be able to add their own scripts. People do this all the time with SL Exchange boxes to see how they work.

LSL is too slow and its XML-RPC implementation too limited for any kind of effective encryption. If someone is picking up your messages, you should assume they know what you're saying, no matter what lengths you go to hide it.

To prevent people from forging messages, you can have a shared secret and use it to sign every message. llMD5String() can become somewhat useful in this situation, but you'll sacrifice 22-32 bytes of the 255 that XML-RPC gives you to work with. For a serious application, the secret should only exist in the script's memory, since past events have shown that you cannot rely on the source code being protected. You can also prevent replay attacks by using a timestamp or some kind of message id that is never recycled. Unix timestamps are perfect, since both llMD5String() and XML-RPC requests take an integer parameter.

I've had 3 different XML-RPC scripts running in the same prim with no interference, so I am pretty sure remote_data events are per-script.

This is a very good assumption,but thank you for reinforcing my thoughts.



Strangely, this is exactly what I'm 'stuggling' with now I like the idea of storing the 'key' in memory, but this obviously implies something 'automagically' created and 'shared' by both halves of the channel. The main question that remains is how do you share this 'key' securely

Thanks
Leon

Good to hear.