Security Enhancement - Add identifying info to llEmail() messages

As :ahem: events of yesterday have shown, there is currently no way to programmatically verify the source of email messages sent via llEmail(). This caused quite a stir with many different services that rely on llEmail() for secure communication.

I propose the Asset UUID and the OWNER's user key be added to the SL-specific "headers" that are automatically included in these messages. This will allow us to add checks in our code so spoofing exploits can be avoided.

You still can't trust the email messages as coming from SL, so it wouldn't help. You could easily be spoofed into thinking it was coming from SL when it really wasn't.

You could, however, setup some kind of digital signature, like a one-time-pad of strings stored on a prim server inworld that would pull a key and use it only once. A corresponding list of the same one-time-pad of strings would be used for verification on the out-world side.

To make security a reality in SL, LL really needs to implement LSL built-in-support for the RSA encryption algorithm (digital signing with a private/public key pair and encryption).

Good points.

"You know you've played SL too much when you can no longer think of situations NOT involving SL." heh, duh

It would still be really helpful to have identifying info in the email though.

I think the one-time pad prim is not such a good idea. If rumors prove true and this latest exploit allowed the attackers to grab in-world prim source code, then they could easily finger through the list of one time keys.

How bout GNUPG keys that sign every email leaving the LL mail server? Then in your off-world server you just make a call to GNUPG to verify that the email did indeed come from SL.

Having the SL e-mails signed by LL, with custom headers, would probably be the best fix.

An easy solution for the moment is to check that the e-mail is "From" lsl.secondlife.com, and then reply to it with a token. The original SL object receives the cookie and resends the message with the token included. Alternatively, the object can request a token good for a finite period of time (say six hours) and cache it.

There are a few other details, like ensuring that objects do not get confused when receiving unexpected tokens, but they are fairly easy to deal with. If I am avoiding work this afternoon I may well throw something together

Actually, I used that system in my HRCE L$ Exchange ATM system (source code available, open source). However, the keys were loaded into script memory, not into the scripts themselves. So you'd have to hack the sim servers themselves and read from memory. The current exploit wouldn't foil that protection scheme.

Basically you create a notecard in your personal inventory (people can't access that though the hack), then copy the key to the keyboard. You have the ATM send you a random channel to chat the key. The ATM hears the key and then reads the notecard, loading each string into dynamic memory. You then delete the notecard from your inventory.

The best thing I've come up with so far is jsut making my message a CSV and adding encryption to the message body itself.

Of course, if someone has your source, your fairly well screwed no matter what

btw, they have a llModPow() function that can do quite limited RSA.