Keeping secrets in your LSL scripts

by Jean Zee (a.k.a. CmpZ)

created Monday, 2021 October 4
updated Monday, 2021 October 4

What is this?

• I wrote a way that LSL scripts & external web servers can authenticate each other. I called it FakeMAC.[00]
• When writing it, I learned that the permissions you should set on your Second Life objects, scripts, & notecards can be tricky depending on what you want to accomplish.
• So here are some use cases & recommendations for each.

Use Cases

Every one of these begins with “As the {creator, owner} of the object, I want it to...”

UC5. Allow others to interact with it while also supporting {free, libre, open} source software

This is a simple case, & Jean recommends it when it's applicable because {free, libre, open} source software benefits us all (even if it's just LSL scripts).

1. Notecard
   • Put a notecard in the object.
   • Mark the notecard as No Copy, No Modify.
   • Put the shared secret on a notecard in the object.
   • IUt doesn't hurt to put your web server's endpoint on the notecard, too.
2. Your LSL script(s)
   • Put your LSL script(s) in the object.
   • Mark them as Copy but No Modify. (Yay free software!) (Protects against M10.)
   • For security purposes, doesn't matter whether next owner can Copy, Modify, or Transfer. (So I suggest letting next owner do all of those.)
3. Object itself: Mark it No Copy, No Modify. (Protects against M17.)

Vend my object to others so they can own it without mucking with FakeMAC authentication

In this use case, you have a vendor object that gives copies of a product object. Your customer gets a copy of your product object, & he owns it. The product object interacts with your web server, & you want to ensure that only your original, un-tampered products are doing so.

For your product object...

1. Put your shared secret (& server's endpoint) on a notecard. Mark the notecard No Copy, No Modify.
2. Put your LSL scripts in the object. Mark them No Modify. You can mark them Copy if you want (I think it's a good idea).
3. Mark the product itself as No Modify. Depending on your use case, you might make it Copyable or No Copy.

Mark your vendor object as No Copy, No Modify.

Misbehaviours (a.k.a. Attacks)

Most of these begin with “As a miscreant in the matrix, I might try to...”

M11. Modify your LSL script to tell me the shared secret

At some point, your LSL script must know the shared secret. You hard-coded it, the script reads it from a notecard, or maybe the script obtains the shared secret from somewhere else. At some point, the script has the secret.

If the miscreant can edit your script, she can make it send the secret to her.

(It's okay if others can make their own copy of your script, but they must not be allowed to alter your script where it sits in your object.)

M17. Add my own script to your object

If the miscreant can add her own LSL script to your object, & your shared secret is in a notecard, her script can fetch the secret & tell it to her.

M23. Copy your object to obtain a modifiable version

If your object allows Copying, & if the next owner can Modify, then our matrix miscreant could make a copy & try the attacks above (modifying a script in her copy or adding a new script to her copy).

Notes

00. Authentication for scripts in Second Life & the web servers they talk to

By Jean Zee. 2021 September 20. http://cybertiggyr.com/fakemac.html

01. llSHA1String

llSHA1String

02. HMAC

HMAC is an acronym for Hashed Message Authentication Code. See HMAC at Wikipedia.

03. copy from fakemac.lsl

Notice that the Fake_MAC code is covered by the Gnu General Public License.

Changes

Jean Zee's 2nd L blog